digitalmars.D.learn - GC.BlkAttr.FINALIZE
- Namespace (20/20) Feb 28 2014 Is it my misunderstanding or does FINALIZE not work?
- Namespace (3/3) Feb 28 2014 Oh man I need sleep. Of course it is 2 at the end of the scope.
- Steven Schveighoffer (8/10) Feb 28 2014 FINALIZE expects the layout of the block to be an Object. You aren't
- Namespace (5/17) Feb 28 2014 Ah! That's not in the docs. :P
- Namespace (2/4) Feb 28 2014 Since I expect/fear that such a implementation is not done in the
- Steven Schveighoffer (8/12) Feb 28 2014 Examine the GC code, and figure out a way to hook the finalizer. Look fo...
- Namespace (6/19) Mar 01 2014 I tried to enable the printf's in rt/lifetime.d (e.g.:
- Steven Schveighoffer (6/10) Mar 02 2014 Enabling debugging code in druntime is really hard. I remember strugglin...
- Namespace (4/15) Mar 02 2014 Great... :D I have no idea how. :P Should I recompile phobos
- Steven Schveighoffer (5/22) Mar 02 2014 You HAVE to recompile phobos, because druntime is statically included
- Namespace (3/27) Mar 02 2014 Ahh.. I thought it is enough to recompile druntime... :)
- Namespace (6/6) Mar 02 2014 It's working now, I get all my debug infos I need.
- Namespace (20/27) Mar 03 2014 I get the real TypeInfo (not sure if this was intended this way)
- Steven Schveighoffer (5/30) Mar 03 2014 Not really any clue.
- Namespace (3/43) Mar 03 2014 Even without I get this weird error. Is this a bug?
- Steven Schveighoffer (6/48) Mar 03 2014 It sounds suspicious. Clearly, you are not accessing a1 there, and clear...
- Namespace (29/33) Mar 03 2014 I don't know. But I know that my little trick doesn't work in
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.
Feb 28 2014
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.
Feb 28 2014
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
Feb 28 2014
"Namespace" <rswhite4 googlemail.com> 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:Ah! That's not in the docs. :P I thougth we got already some implementations. What is the status on this?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
Feb 28 2014
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?
Feb 28 2014
On Fri, 28 Feb 2014 18:45:50 -0500, Namespace <rswhite4 googlemail.com> wrote: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.). -SteveWe 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?
Feb 28 2014
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:I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/ t/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.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.). -SteveWe 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?
Mar 01 2014
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/ t/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
Mar 02 2014
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:Great... :D I have no idea how. :P Should I recompile phobos also? Or try something special...?I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/ t/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
Mar 02 2014
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:You HAVE to recompile phobos, because druntime is statically included inside it ;) -SteveOn Sat, 01 Mar 2014 09:57:44 -0500, Namespace <rswhite4 googlemail.com> wrote:Great... :D I have no idea how. :P Should I recompile phobos also? Or try something special...?I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/ t/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
Mar 02 2014
On Sunday, 2 March 2014 at 20:45:42 UTC, Steven Schveighoffer wrote:On Sun, 02 Mar 2014 15:44:47 -0500, Namespace <rswhite4 googlemail.com> wrote:Ahh.. I thought it is enough to recompile druntime... :)On Sunday, 2 March 2014 at 20:21:51 UTC, Steven Schveighoffer wrote:You HAVE to recompile phobos, because druntime is statically included inside it ;) -SteveOn Sat, 01 Mar 2014 09:57:44 -0500, Namespace <rswhite4 googlemail.com> wrote:Great... :D I have no idea how. :P Should I recompile phobos also? Or try something special...?I tried to enable the printf's in rt/lifetime.d (e.g.: https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/ t/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
Mar 02 2014
It's working now, I get all my debug infos I need. But: I have absolutly no idea how to get the correct TypeInfo in rt_finalize2. The ClassInfo is identified by casting the void* pointer to a void** and then cast this void** to ClassInfo*. But for other TypeInfos this weird trick doesn't work. How can I extract the correct TypeInfo from this void**? :P
Mar 02 2014
On Monday, 3 March 2014 at 02:44:09 UTC, Namespace wrote:It's working now, I get all my debug infos I need. But: I have absolutly no idea how to get the correct TypeInfo in rt_finalize2. The ClassInfo is identified by casting the void* pointer to a void** and then cast this void** to ClassInfo*. But for other TypeInfos this weird trick doesn't work. How can I extract the correct TypeInfo from this void**? :PI get the real TypeInfo (not sure if this was intended this way) and in my test base it works! But in druntime I get the weird error: src\rt\lifetime.d(1256): Error: variable a1 used before set ---- if (gc_getAttr(p) & BlkAttr.APPENDABLE) { void[] a1 = *cast(void[]*) ppv; //printf("len = %d\n", a1.length); void* p_a1 = &a1; void* tp = p_a1 + 12; TypeInfo* ti = cast(TypeInfo*) tp; import std.string : toStringz; string s = ti.toString(); // line 1256 printf("Type = %s\n", toStringz(s)); return; } ---- Any call to ti will invoke the error. Any idea why?
Mar 03 2014
On Mon, 03 Mar 2014 12:03:12 -0500, Namespace <rswhite4 googlemail.com> wrote:On Monday, 3 March 2014 at 02:44:09 UTC, Namespace wrote:Not really any clue. But if this is in druntime, it should not be importing anything from std. -SteveIt's working now, I get all my debug infos I need. But: I have absolutly no idea how to get the correct TypeInfo in rt_finalize2. The ClassInfo is identified by casting the void* pointer to a void** and then cast this void** to ClassInfo*. But for other TypeInfos this weird trick doesn't work. How can I extract the correct TypeInfo from this void**? :PI get the real TypeInfo (not sure if this was intended this way) and in my test base it works! But in druntime I get the weird error: src\rt\lifetime.d(1256): Error: variable a1 used before set ---- if (gc_getAttr(p) & BlkAttr.APPENDABLE) { void[] a1 = *cast(void[]*) ppv; //printf("len = %d\n", a1.length); void* p_a1 = &a1; void* tp = p_a1 + 12; TypeInfo* ti = cast(TypeInfo*) tp; import std.string : toStringz; string s = ti.toString(); // line 1256 printf("Type = %s\n", toStringz(s)); return; } ---- Any call to ti will invoke the error. Any idea why?
Mar 03 2014
On Monday, 3 March 2014 at 18:36:56 UTC, Steven Schveighoffer wrote:On Mon, 03 Mar 2014 12:03:12 -0500, Namespace <rswhite4 googlemail.com> wrote:Even without I get this weird error. Is this a bug?On Monday, 3 March 2014 at 02:44:09 UTC, Namespace wrote:Not really any clue. But if this is in druntime, it should not be importing anything from std. -SteveIt's working now, I get all my debug infos I need. But: I have absolutly no idea how to get the correct TypeInfo in rt_finalize2. The ClassInfo is identified by casting the void* pointer to a void** and then cast this void** to ClassInfo*. But for other TypeInfos this weird trick doesn't work. How can I extract the correct TypeInfo from this void**? :PI get the real TypeInfo (not sure if this was intended this way) and in my test base it works! But in druntime I get the weird error: src\rt\lifetime.d(1256): Error: variable a1 used before set ---- if (gc_getAttr(p) & BlkAttr.APPENDABLE) { void[] a1 = *cast(void[]*) ppv; //printf("len = %d\n", a1.length); void* p_a1 = &a1; void* tp = p_a1 + 12; TypeInfo* ti = cast(TypeInfo*) tp; import std.string : toStringz; string s = ti.toString(); // line 1256 printf("Type = %s\n", toStringz(s)); return; } ---- Any call to ti will invoke the error. Any idea why?
Mar 03 2014
On Mon, 03 Mar 2014 15:34:18 -0500, Namespace <rswhite4 googlemail.com> wrote:On Monday, 3 March 2014 at 18:36:56 UTC, Steven Schveighoffer wrote:It sounds suspicious. Clearly, you are not accessing a1 there, and clearly a1 is set before being used. Any chance to reduce it? -SteveOn Mon, 03 Mar 2014 12:03:12 -0500, Namespace <rswhite4 googlemail.com> wrote:Even without I get this weird error. Is this a bug?On Monday, 3 March 2014 at 02:44:09 UTC, Namespace wrote:Not really any clue. But if this is in druntime, it should not be importing anything from std.It's working now, I get all my debug infos I need. But: I have absolutly no idea how to get the correct TypeInfo in rt_finalize2. The ClassInfo is identified by casting the void* pointer to a void** and then cast this void** to ClassInfo*. But for other TypeInfos this weird trick doesn't work. How can I extract the correct TypeInfo from this void**? :PI get the real TypeInfo (not sure if this was intended this way) and in my test base it works! But in druntime I get the weird error: src\rt\lifetime.d(1256): Error: variable a1 used before set ---- if (gc_getAttr(p) & BlkAttr.APPENDABLE) { void[] a1 = *cast(void[]*) ppv; //printf("len = %d\n", a1.length); void* p_a1 = &a1; void* tp = p_a1 + 12; TypeInfo* ti = cast(TypeInfo*) tp; import std.string : toStringz; string s = ti.toString(); // line 1256 printf("Type = %s\n", toStringz(s)); return; } ---- Any call to ti will invoke the error. Any idea why?
Mar 03 2014
It sounds suspicious. Clearly, you are not accessing a1 there, and clearly a1 is set before being used. Any chance to reduce it? -SteveI don't know. But I know that my little trick doesn't work in lifetime.d although it works locally. Here what I tried: ---- import std.stdio; struct Foo { int id; } void main() { Foo[] fs; fs ~= Foo(45); fs ~= Foo(46); fs ~= Foo(47); fs ~= Foo(48); auto ti = typeid(fs); writeln("&ti = ", &ti); void* p = fs.ptr; void[] arr = *cast(void[]*) p; void* tp = cast(void*)((&arr) - cast(void*) 8); TypeInfo ti2 = *cast(TypeInfo*) tp; writeln(ti, " versus ", ti2); } ---- Since rt_finalize and the GC have the same pointer as 'fs.ptr' I cast it to an array struct. From the pointer of this struct I subtract 8 (8 because of try and error until the pointer was equal the real TypeInfo pointer). This I can cast to the TypeInfo: it works. But not in lifetime.d. Was a try, but I have no idea why it doesn't work (the pointers aren't equal). An idea or alternative?
Mar 03 2014