www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Finalize GC memory

reply "Namespace" <rswhite4 googlemail.com> writes:
With the knowledge that 'delete' will be deprecated soon:
Is there then still a way to finalize GC memory? I know it's 
unsafe etc. but is there a way? I know of 'destroy' but it does 
not finalize anything and AFAIK it's not safe and has also side 
effects. And it does not call the DTor if any struct is allocated 
with 'new'.
I tried GC.free, GC.collect, destroy and a few other things, but 
except of 'delete' nothing finalize the memory.
Thoughts?
Jun 15 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I assume the silence means no?
Jun 16 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/15/2013 02:22 PM, Namespace wrote:

 With the knowledge that 'delete' will be deprecated soon:
 Is there then still a way to finalize GC memory? I know it's unsafe etc.
 but is there a way? I know of 'destroy' but it does not finalize
 anything and AFAIK it's not safe and has also side effects.
Being a C++ programmer, I am new to the term "finalize". If it means "call the destructor", then destroy() is it.
 And it does
 not call the DTor if any struct is allocated with 'new'.
It does: import std.stdio; struct S { ~this() { writeln("destructor called"); } } void main() { auto s = new S(); destroy(*s); // NOTE the '*' operator! }
 I tried GC.free, GC.collect, destroy and a few other things, but except
 of 'delete' nothing finalize the memory.
 Thoughts?
Ali
Jun 16 2013
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Being a C++ programmer, I am new to the term "finalize". If it 
 means "call the destructor", then destroy() is it.
Finalize -> free the memory immediately as 'delete' it does currently.
 And it does
 not call the DTor if any struct is allocated with 'new'.
It does: import std.stdio; struct S { ~this() { writeln("destructor called"); } } void main() { auto s = new S(); destroy(*s); // NOTE the '*' operator! }
Good to know!
Jun 16 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
I have adjusted the thread title.
Jun 16 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 16, 2013 12:24:40 Ali =C3=87ehreli wrote:
 On 06/15/2013 02:22 PM, Namespace wrote:
  > With the knowledge that 'delete' will be deprecated soon:
  > Is there then still a way to finalize GC memory? I know it's unsaf=
e etc.
  > but is there a way? I know of 'destroy' but it does not finalize
  > anything and AFAIK it's not safe and has also side effects.
=20
 Being a C++ programmer, I am new to the term "finalize". If it means
 "call the destructor", then destroy() is it.
http://en.wikipedia.org/wiki/Finalizer It's basically just means calling the finalizer, and D conflates finali= zers and=20 destructors, so the destructor of any object on the GC heap is that obj= ect's=20 finalizer. Normally, it's called when the object is collected, but it c= an get a=20 bit messy depending on how the GC works. It's essentially a non-determi= nstic=20 destructor though. - Jonathan M Davis
Jun 16 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 http://en.wikipedia.org/wiki/Finalizer

 It's basically just means calling the finalizer, and D 
 conflates finalizers and
 destructors, so the destructor of any object on the GC heap is 
 that object's
 finalizer. Normally, it's called when the object is collected, 
 but it can get a
 bit messy depending on how the GC works. It's essentially a 
 non-determinstic
 destructor though.

 - Jonathan M Davis
It was my fault. What I meant was to release GC memory immediately.
Jun 16 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
It seems that does what I want. The result is the same as with 
the current 'delete' implementation.

----
void Delete(T)(ref T var) {
	static if (is(T == struct) && is(typeof(var.__dtor)))
		var.__dtor();
		
	static if (is(T : U[], U))
		core.memory.GC.free(var.ptr);
	else {
		static if (is(T : U*, U))
			core.memory.GC.free(var);
		else
			core.memory.GC.free(&var);
	}
}
----

But if I call 'destroy' before I call GC.free, it does not work 
correct.
Jun 16 2013
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 16 June 2013 at 21:37:16 UTC, Namespace wrote:
 It seems that does what I want. The result is the same as with 
 the current 'delete' implementation.

 ----
 void Delete(T)(ref T var) {
 	static if (is(T == struct) && is(typeof(var.__dtor)))
 		var.__dtor();
 		
 	static if (is(T : U[], U))
 		core.memory.GC.free(var.ptr);
 	else {
 		static if (is(T : U*, U))
 			core.memory.GC.free(var);
 		else
 			core.memory.GC.free(&var);
 	}
 }
 ----

 But if I call 'destroy' before I call GC.free, it does not work 
 correct.
I forget 'var = null;'. But: Any thoughts on this? Will it work as I want? In my few tests it seems to work like delete, but I would be interested in the meaning of some experts.
Jun 17 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, June 17, 2013 18:46:29 Namespace wrote:
 On Sunday, 16 June 2013 at 21:37:16 UTC, Namespace wrote:
 It seems that does what I want. The result is the same as with
 the current 'delete' implementation.
 
 ----
 void Delete(T)(ref T var) {
 
 static if (is(T == struct) && is(typeof(var.__dtor)))
 
 var.__dtor();
 
 static if (is(T : U[], U))
 
 core.memory.GC.free(var.ptr);
 
 else {
 
 static if (is(T : U*, U))
 
 core.memory.GC.free(var);
 
 else
 
 core.memory.GC.free(&var);
 
 }
 
 }
 ----
 
 But if I call 'destroy' before I call GC.free, it does not work
 correct.
I forget 'var = null;'. But: Any thoughts on this? Will it work as I want? In my few tests it seems to work like delete, but I would be interested in the meaning of some experts.
I'd be worried about whether it actually called the destructors of the members of the struct. IIRC, you actually have to play around with TypeInfo in order to be able to correctly manually destroy a struct rather than simply calling its __dtor method, but it's not something that I ever do, so I don't remember the details. Regardless, if destroy doesn't actually destroy a struct correctly, then that's a bug and should be reported. - Jonathan M Davis
Jun 17 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 I'd be worried about whether it actually called the destructors 
 of the members
 of the struct. IIRC, you actually have to play around with 
 TypeInfo in order
 to be able to correctly manually destroy a struct rather than 
 simply calling
 its __dtor method, but it's not something that I ever do, so I 
 don't remember
 the details. Regardless, if destroy doesn't actually destroy a 
 struct
 correctly, then that's a bug and should be reported.

 - Jonathan M Davis
Why the members could not be destroyed? Could you give me an example? And did you have a link, that explain how I should use TypeInfo to destroy the struct correctly?
Jun 18 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 18 Jun 2013 03:59:37 -0400, Namespace <rswhite4 googlemail.com>  
wrote:

 I'd be worried about whether it actually called the destructors of the  
 members
 of the struct. IIRC, you actually have to play around with TypeInfo in  
 order
 to be able to correctly manually destroy a struct rather than simply  
 calling
 its __dtor method, but it's not something that I ever do, so I don't  
 remember
 the details. Regardless, if destroy doesn't actually destroy a struct
 correctly, then that's a bug and should be reported.

 - Jonathan M Davis
Why the members could not be destroyed? Could you give me an example? And did you have a link, that explain how I should use TypeInfo to destroy the struct correctly?
Be careful what hidden members you call, some of them are not what you think they are. As a guide, you should take a look at the destroy function in object to see the proper method of destroying things. -Steve
Jun 18 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Be careful what hidden members you call, some of them are not 
 what you think they are.
For example?
 As a guide, you should take a look at the destroy function in 
 object to see the proper method of destroying things.

 -Steve
Jun 18 2013
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 18 Jun 2013 09:34:44 -0400, Namespace <rswhite4 googlemail.com>  
wrote:

 Be careful what hidden members you call, some of them are not what you  
 think they are.
For example?
For example, __dtor may not be the full destructor, but just the code represented by ~this(). I think this is the case for structs. I have a bug report somewhere, let me see... Oops, not my bug, but I commented on it :) See comment 6 from Kenji: http://d.puremagic.com/issues/show_bug.cgi?id=5667#c6 -Steve
Jun 18 2013
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I must ask again:
http://dlang.org/phobos/core_memory.html#.GC.free
  -> The block will not be finalized regardless of whether the 
FINALIZE attribute is set. If finalization is desired, use delete 
instead.

In knowledge of this: How can I *finalize* GC memory? delete is 
or will be deprecated soon.
Jul 04 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 16 Jun 2013 17:37:15 -0400, Namespace <rswhite4 googlemail.com>  
wrote:

 But if I call 'destroy' before I call GC.free, it does not work correct.
Destroy puts anything back into it's initial state. So for anything that is a pointer, destroy will set it to null! Then calling GC free on null is no good. What you have to do is save a copy of the pointer, to pass to GC.free later. -Steve
Jun 17 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 17 June 2013 at 17:09:45 UTC, Steven Schveighoffer 
wrote:
 On Sun, 16 Jun 2013 17:37:15 -0400, Namespace 
 <rswhite4 googlemail.com> wrote:

 But if I call 'destroy' before I call GC.free, it does not 
 work correct.
Destroy puts anything back into it's initial state. So for anything that is a pointer, destroy will set it to null! Then calling GC free on null is no good. What you have to do is save a copy of the pointer, to pass to GC.free later. -Steve
Ok, thanks. And you think that my code is working as intended? Or have I overlooked something obvious.
Jun 17 2013
prev sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
Here my new version:
----
void Delete(T)(ref T var) if (isAssignable!(T, typeof(null)) && 
!isStaticArray!T) {
	const bool isPtr = is(T : U*, U);

	static if (isPtr && (is(U == struct) || is(U == class)))
		.destroy(*var);

	static if (is(T : U[], U))
		GC.free(var.ptr);
	else {
		static if (isPtr)
			GC.free(var);
		else
			GC.free(&var);
	}

	var = null;
}
----

That should fulfill all wishes. :)
Jun 18 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Namespace:

 Here my new version:
 ----
 void Delete(T)(ref T var) if (isAssignable!(T, typeof(null)) && 
 !isStaticArray!T) {
 ...
 ----

 That should fulfill all wishes. :)
Its name should start with a lowercase, according to the D style. Bye, bearophile
Jun 18 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Tuesday, 18 June 2013 at 09:16:05 UTC, bearophile wrote:
 Namespace:

 Here my new version:
 ----
 void Delete(T)(ref T var) if (isAssignable!(T, typeof(null)) 
 && !isStaticArray!T) {
 ...
 ----

 That should fulfill all wishes. :)
Its name should start with a lowercase, according to the D style. Bye, bearophile
Maybe, but 'delete' is already a keyword and 'destroy' already exists.
Jun 18 2013
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Just for you:
http://dpaste.1azy.net/3b46c669

This code works now perfect and works also with forward 
referenced opaque structures.
Jun 18 2013