Is it my misunderstanding or does FINALIZE not work?

----
import std.stdio;
import core.memory : GC;

void main() {
	int id = 2;

	struct Foo {
		~this() {
			id--;
			writeln("DTor");
		}
	}

	Foo* fs = cast(Foo*) GC.malloc(2 * Foo.sizeof, GC.BlkAttr.FINALIZE);

	writeln("end of main: ", id);
}
----

id is still 2. I know that the GC is incapable with arrays of structs but if FINALIZE means the same thing I expect, it should work. Otherwise the docs should be updated.

Oh man I need sleep. Of course it is 2 at the end of the scope. But what is important: I never see "DTor". So the Data is not finalized.

On Fri, 28 Feb 2014 18:26:29 -0500, Namespace <rswhite4@googlemail.com> wrote:

> Oh man I need sleep. Of course it is 2 at the end of the scope. But what is important: I never see "DTor". So the Data is not finalized.

FINALIZE expects the layout of the block to be an Object. You aren't implementing the correct internals. Specifically, you need a vtable, which will point at the dtor. I'm surprised you don't get a segfault.

We need a precise GC to get struct dtors to work, the alternative would be extremely hackish.

-Steve

On Friday, 28 February 2014 at 23:30:46 UTC, Steven Schveighoffer wrote:
> On Fri, 28 Feb 2014 18:26:29 -0500, Namespace <rswhite4@googlemail.com> wrote:
>
>> Oh man I need sleep. Of course it is 2 at the end of the scope. But what is important: I never see "DTor". So the Data is not finalized.
>
> FINALIZE expects the layout of the block to be an Object. You aren't implementing the correct internals. Specifically, you need a vtable, which will point at the dtor. I'm surprised you don't get a segfault.
>
> We need a precise GC to get struct dtors to work, the alternative would be extremely hackish.
>
> -Steve

Ah! That's not in the docs. :P
I thougth we got already some implementations. What is the status on this?

> We need a precise GC to get struct dtors to work, the alternative would be extremely hackish.

Since I expect/fear that such a implementation is not done in the next 12 months: what would be the alternative?

On Fri, 28 Feb 2014 18:45:50 -0500, Namespace <rswhite4@googlemail.com> wrote:

>> We need a precise GC to get struct dtors to work, the alternative would be extremely hackish.
>
> Since I expect/fear that such a implementation is not done in the next 12 months: what would be the alternative?

Examine the GC code, and figure out a way to hook the finalizer. Look for FINALIZE.

Another crude but effective option would be to wrap the struct in a class. May not actually be that bad, depending on the size of the struct (blocks come in chunks of 16, 32, 64, etc.).

-Steve

On Saturday, 1 March 2014 at 01:28:06 UTC, Steven Schveighoffer wrote:
> On Fri, 28 Feb 2014 18:45:50 -0500, Namespace <rswhite4@googlemail.com> wrote:
>
>>> We need a precise GC to get struct dtors to work, the alternative would be extremely hackish.
>>
>> Since I expect/fear that such a implementation is not done in the next 12 months: what would be the alternative?
>
> Examine the GC code, and figure out a way to hook the finalizer. Look for FINALIZE.
>
> Another crude but effective option would be to wrap the struct in a class. May not actually be that bad, depending on the size of the struct (blocks come in chunks of 16, 32, 64, etc.).
>
> -Steve

I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1125) to see what happens if I/the GC delete an array. But I see no output, no matter what I try to allocate/deallocate.

On Sat, 01 Mar 2014 09:57:44 -0500, Namespace <rswhite4@googlemail.com> wrote:

>
> I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1125) to see what happens if I/the GC delete an array. But I see no output, no matter what I try to allocate/deallocate.

Enabling debugging code in druntime is really hard. I remember struggling with that when I was changing the array append code. It does work when you get it right...

-Steve

On Sunday, 2 March 2014 at 20:21:51 UTC, Steven Schveighoffer wrote:
> On Sat, 01 Mar 2014 09:57:44 -0500, Namespace <rswhite4@googlemail.com> wrote:
>
>>
>> I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1125) to see what happens if I/the GC delete an array. But I see no output, no matter what I try to allocate/deallocate.
>
> Enabling debugging code in druntime is really hard. I remember struggling with that when I was changing the array append code. It does work when you get it right...
>
> -Steve

Great... :D I have no idea how. :P Should I recompile phobos also? Or try something special...?

On Sun, 02 Mar 2014 15:44:47 -0500, Namespace <rswhite4@googlemail.com> wrote:

> On Sunday, 2 March 2014 at 20:21:51 UTC, Steven Schveighoffer wrote:
>> On Sat, 01 Mar 2014 09:57:44 -0500, Namespace <rswhite4@googlemail.com> wrote:
>>
>>>
>>> I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/lifetime.d#L1125) to see what happens if I/the GC delete an array. But I see no output, no matter what I try to allocate/deallocate.
>>
>> Enabling debugging code in druntime is really hard. I remember struggling with that when I was changing the array append code. It does work when you get it right...
>>
>> -Steve
>
> Great... :D I have no idea how. :P Should I recompile phobos also? Or try something special...?

You HAVE to recompile phobos, because druntime is statically included inside it ;)

-Steve