www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - struct destructors

reply Alexander <aldem+dmars nk7.net> writes:
Are those supposed to be called when struct was allocated on the heap and is
collected by GC?

According to my observations (DMD 2.052 Linux), they are called only when:
- struct is allocated on the stack and goes out of scope;
- explicit delete is called on heap-allocated struct.

/Alexander
May 09 2011
parent reply Sean Kelly <sean invisibleduck.org> writes:
On May 9, 2011, at 9:21 AM, Alexander wrote:


 Are those supposed to be called when struct was allocated on the heap =


and is collected by GC?

Not currently.  I thought I wrote some explanation of why... somewhere, =
but I can't find it right now (2834 is the ticket number for this issue, =
but my comments aren't in there).  Maybe it was just that this will be a =
technically difficult problem to solve.  I'll do some more searching and =
see if I can turn out that comment.=
May 09 2011
parent reply Alexander <aldem+dmars nk7.net> writes:
On 09.05.2011 19:38, Sean Kelly wrote:


 Not currently.  I thought I wrote some explanation of why...


  OK, thanks - I've read the ticket. Though, the problem can be solved
relatively simple, IMHO - adding one more pointer to BlkInfo, where address of
the finalizer is stored, which will be used only for cases when collected
object is not a class.

  For now, it seems, better to avoid struct destructors at all, or resort to
classes.

/Alexander
May 09 2011
parent reply Sean Kelly <sean invisibleduck.org> writes:
On May 9, 2011, at 12:51 PM, Alexander wrote:


 On 09.05.2011 19:38, Sean Kelly wrote:
=20

 Not currently.  I thought I wrote some explanation of why...


=20
  OK, thanks - I've read the ticket. Though, the problem can be solved =


relatively simple, IMHO - adding one more pointer to BlkInfo, where =
address of the finalizer is stored, which will be used only for cases =
when collected object is not a class.

Well... BlkInfo is generated from a selection of internal sources.  =
You're right that the GC would need to store a finalizer reference for =
structs, but that's just the simple case.  It would also need to =
finalize structs in dynamic arrays and AA nodes as well (though it's =
possible the latter already works, since the AA is now template code).  =
And of course the finalizer reference would have to be passed to =
GC.malloc() or whatever so that portion of the API would change as well. =
 I originally held off on fixing this because its requirements seemed to =
fit nicely with the requirements for precise scanning (ie. passing the =
GC some TypeInfo so it can be smarter about how it deals with allocated =
memory blocks in general), and I wanted to do both at once.  But I have =
a feeling that I came up with some other problem regarding struct =
finalization, so I want to see if I can find that old email or whatever =
to be sure.=
May 09 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 09 May 2011 17:04:49 -0400, Sean Kelly <sean invisibleduck.org>  
wrote:


 On May 9, 2011, at 12:51 PM, Alexander wrote:


 On 09.05.2011 19:38, Sean Kelly wrote:


 Not currently.  I thought I wrote some explanation of why...


  OK, thanks - I've read the ticket. Though, the problem can be solved  
 relatively simple, IMHO - adding one more pointer to BlkInfo, where  
 address of the finalizer is stored, which will be used only for cases  
 when collected object is not a class.


 Well... BlkInfo is generated from a selection of internal sources.   
 You're right that the GC would need to store a finalizer reference for  
 structs, but that's just the simple case.  It would also need to  
 finalize structs in dynamic arrays and AA nodes as well (though it's  
 possible the latter already works, since the AA is now template code).   
 And of course the finalizer reference would have to be passed to  
 GC.malloc() or whatever so that portion of the API would change as  
 well.  I originally held off on fixing this because its requirements  
 seemed to fit nicely with the requirements for precise scanning (ie.  
 passing the GC some TypeInfo so it can be smarter about how it deals  
 with allocated memory blocks in general), and I wanted to do both at  
 once.  But I have a feeling that I came up with some other problem  
 regarding struct finalization, so I want to see if I can find that old  
 email or whatever to be sure.


A few things here:

1. the reason why a struct is not finalized when allocated on the heap is  
because a struct does not have a vtable pointer (which is how the GC is  
able to find the dtor for a class).
2. A struct allocated on the heap is actually transformed by the compiler  
into an allocation of an array of one struct instance.  So essentially  
there is one problem to solve -- how to finalize an array of structs.
3. AA's are templated, but the templated functions simply forward to the  
runtime functions.  The template allows us to add extra functionality to  
an AA without modifying the compiler, but everything is very much done by  
druntime.  However, I think we would have the ability to add this without  
modifying the compiler.

-Steve
May 16 2011