www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC does not delete subclass

reply Matthias Thurau <Matthiasth gmx.de> writes:
Hi,
I just made some small examples for myself to understand the GC. Here i have a
testcase, that has an unexpected behavior for me:



import std.stdio;

static int number   =   0;
static int number2   =   0;

class MyClass {
public:
  this()    {   writefln("Constructor %d", number);
                myNumber = number; number++;
                member  =   new My2Class(); };
  ~this()   {   writefln("Destructor %d", myNumber); };

  My2Class    member;

  int myNumber;
};

class My2Class {
public:
  this()    {   writefln("Sub_Constructor2 %d", number2);
                myNumber2 = number2; number2++; };
  ~this()   {   writefln("Sub_Destructor2 %d", myNumber2); };

  int myNumber2;
};




int main(char[][] args) {
    {
        scope MyClass A  =    new MyClass();
    }

    std.gc.fullCollect();

    writefln("The Sub Class from 0 does not get deleted yet!");

    MyClass C   =    new MyClass();

    return 0;
};



The Output ist: 

Constructor 0
Sub_Constructor2 0
Destructor 0
The Sub Class from 0 does not get deleted yet!
Constructor 1
Sub_Constructor2 1
Sub_Destructor2 1
Destructor 1
Sub_Destructor2 0
Dec 17 2007
parent reply Matthias Thurau <Matthiasth gmx.de> writes:
BTW:
This is working correctly:

void func() {
    MyClass A  =    new MyClass();
};

int main(char[][] args) {
    
    func();

    std.gc.fullCollect();
    writefln("The Sub Class from 0 does not get deleted yet!");
    MyClass C   =    new MyClass();

    return 0;
};

When i put the "scope" into the func(), then i get the output from above again.
The right ouput was in my opinion:
Constructor 0
Sub_Constructor2 0
Sub_Destructor2 0
Destructor 0
The Sub Class from 0 does not get deleted yet!
Constructor 1
Sub_Constructor2 1
Sub_Destructor2 1
Destructor 1
Dec 17 2007
parent reply Jason House <jason.james.house gmail.com> writes:
Matthias Thurau Wrote:

 When i put the "scope" into the func(), then i get the output from above again.
It looks like a bug to me. Does this happen with Phobos or Tango? (or both?) I know they use different gc's.
Dec 17 2007
parent reply Sean Kelly <sean f4.ca> writes:
Jason House wrote:
 Matthias Thurau Wrote:
 
 When i put the "scope" into the func(), then i get the output from above again.
It looks like a bug to me. Does this happen with Phobos or Tango? (or both?) I know they use different gc's.
I've noticed that the most recent object to be constructed is often not deleted in simple test cases. My guess is that a reference to this address is probably still lingering in a register somewhere, so the GC thinks it's still alive. This happens in Phobos and Tango. Sean
Dec 17 2007
parent reply Matthias Thurau <Matthiasth gmx.de> writes:
thanks for replys...

So how do i handle this? Should i ignore that or am i doing something wrong?
(Ist it a bug or not? :)

bye
Dec 18 2007
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Matthias Thurau wrote:

 thanks for replys...
 
 So how do i handle this? Should i ignore that or am i doing something
 wrong? (Ist it a bug or not? :)
 
 bye
It is hardly a bug. You should in any case not depend on an object being collected. Garbage collection is not deterministic. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Dec 18 2007
prev sibling parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Matthias Thurau wrote:
 thanks for replys...
 
 So how do i handle this? Should i ignore that or am i doing something wrong?
(Ist it a bug or not? :)
Ignore it. Most probably no bug! Who has ever claimed that the GC collects objects in any specific order? regards, frank
Dec 18 2007
parent reply Jason House <jason.james.house gmail.com> writes:
0ffh Wrote:

 Matthias Thurau wrote:
 thanks for replys...
 
 So how do i handle this? Should i ignore that or am i doing something wrong?
(Ist it a bug or not? :)
Ignore it. Most probably no bug! Who has ever claimed that the GC collects objects in any specific order?
I don't think it was specifically the order but rather full collection not fully collecting. I haven't tried this, but is it possible to declare class member variables as scope so that they will get deleted when the rest of the object does? This could save coding of custom destructors in some cases.
Dec 18 2007
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jason House" wrote
 0ffh Wrote:

 Matthias Thurau wrote:
 thanks for replys...

 So how do i handle this? Should i ignore that or am i doing something 
 wrong? (Ist it a bug or not? :)
Ignore it. Most probably no bug! Who has ever claimed that the GC collects objects in any specific order?
I don't think it was specifically the order but rather full collection not fully collecting. I haven't tried this, but is it possible to declare class member variables as scope so that they will get deleted when the rest of the object does? This could save coding of custom destructors in some cases.
Custom destructors should NEVER destroy other GC allocated objects. the GC cannot guarantee the order of collection, meaning if you have a pointer to another GC allocated object, that object may have already been collected. There is no real reason to delete other objects in a destructor. If the objects are no longer referenced, the GC will destroy those also. The only things you should destroy in a destructor are non-GC allocated resources, such as file descriptors, or memory allocated with C's malloc. So to answer your question: scope is not necessary as a modifier for a member variable. -Steve
Dec 18 2007
next sibling parent reply Matthias Thurau <Matthiasth gmx.de> writes:
"If the objects are no longer referenced, the GC will destroy those also."

Thats exact the case: In my example the GC isn t destroying that unreferenced
member.
Dec 18 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Matthias Thurau wrote:
 "If the objects are no longer referenced, the GC will destroy those also."
 
 Thats exact the case: In my example the GC isn t destroying that unreferenced
member.
I imagine Sean was correct when he said: "I've noticed that the most recent object to be constructed is often not deleted in simple test cases. My guess is that a reference to this address is probably still lingering in a register somewhere, so the GC thinks it's still alive. This happens in Phobos and Tango." In which case, yes, there is a 'bug' in full collect. Post a bug report, if one does not already exist. :) Regan
Dec 18 2007
parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Regan Heath wrote:
 I imagine Sean was correct when he said:
 
 "I've noticed that the most recent object to be constructed is often not 
 deleted in simple test cases.  My guess is that a reference to this 
 address is probably still lingering in a register somewhere, so the GC 
 thinks it's still alive.  This happens in Phobos and Tango."
 
 In which case, yes, there is a 'bug' in full collect.  Post a bug 
 report, if one does not already exist. :)
Given that Sean is correct (which is plausible), then it is incorrect to speak of a bug (or even a 'bug'). The algorithm works as specified. If someone does not like (or understand) the specification you can hardly (actually, not even remotely) speak of a bug. Sorry for nitpicking, but this is bothering me. regards, frank
Dec 18 2007
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Matthias Thurau" wrote
 "If the objects are no longer referenced, the GC will destroy those also."

 Thats exact the case: In my example the GC isn t destroying that 
 unreferenced member.
My understanding of scope is that the object is supposed to be forcefully deleted at the end of the scope (not through the GC). So in your case, I believe there is a bug, because delete should call the destructor immediately. i.e.: { scope C = new C; } should be equivalent to: { auto C = new C; delete C; } So I believe that the GC shouldn't be calling the destructor in fullcollect, it should be called BEFORE fullcollect is called. Of course, I may be misunderstanding how scope works :) With regards to my response, I just wanted to point out to Jason that destructors should not be used as he was alluding to. -Steve
Dec 18 2007
parent reply Sean Kelly <sean f4.ca> writes:
Steven Schveighoffer wrote:
 "Matthias Thurau" wrote
 "If the objects are no longer referenced, the GC will destroy those also."

 Thats exact the case: In my example the GC isn t destroying that 
 unreferenced member.
My understanding of scope is that the object is supposed to be forcefully deleted at the end of the scope (not through the GC). So in your case, I believe there is a bug, because delete should call the destructor immediately. i.e.: { scope C = new C; } should be equivalent to: { auto C = new C; delete C; } So I believe that the GC shouldn't be calling the destructor in fullcollect, it should be called BEFORE fullcollect is called.
I'm pretty sure that this is what's happening. However, it is only deleting C, not the objects that C points to. This is necessary behavior. Consider: class A {} class B { this( A a ) { val = a; } A val; } void fn( A val ) { scope B = new B( val ); } You certainly wouldn't want the instance of A deleted when fn exits as well. Sean
Dec 18 2007
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote
 I'm pretty sure that this is what's happening.  However, it is only 
 deleting C, not the objects that C points to.  This is necessary behavior. 
 Consider:

     class A
     {}
     class B
     {
         this( A a )
         {
             val = a;
         }
         A val;
     }

     void fn( A val )
     {
         scope B = new B( val );
     }

 You certainly wouldn't want the instance of A deleted when fn exits as 
 well.
Oh! I misunderstood the original post. Yes, I agree that the current behavior should be the expected behavior for the original example. I thought that for some reason the destructor of the scoped class was not getting called when the scope exited. -Steve
Dec 18 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Matthias Thurau wrote:
 "If the objects are no longer referenced, the GC will destroy those also."
 
 Thats exact the case: In my example the GC isn t destroying that unreferenced
member.
Technically, it is. It's just not destroying it in the collection immediately following the object's allocation, which isn't guaranteed anyway. As I said previously, it's likely that a register still holds the address of this object when the allocation is triggered, because basically nothing happens between the object's construction and the collection. In a real application, such things are unlikely occur. Sean
Dec 18 2007
parent reply Gide Nwawudu <gide btinternet.com> writes:
On Tue, 18 Dec 2007 11:45:49 -0800, Sean Kelly <sean f4.ca> wrote:

Matthias Thurau wrote:
 "If the objects are no longer referenced, the GC will destroy those also."
 
 Thats exact the case: In my example the GC isn t destroying that unreferenced
member.
Technically, it is. It's just not destroying it in the collection immediately following the object's allocation, which isn't guaranteed anyway. As I said previously, it's likely that a register still holds the address of this object when the allocation is triggered, because basically nothing happens between the object's construction and the collection. In a real application, such things are unlikely occur.
  ~this()   {   writefln("Destructor %d", myNumber); }
To help the GC, is Java-like null assignment necessary? The following line helps std.gc.fullCollect() to destroy My2Class members. ~this() { writefln("Destructor %d", myNumber); member = null; } Gide
Dec 18 2007
parent reply Sean Kelly <sean f4.ca> writes:
Gide Nwawudu wrote:
 On Tue, 18 Dec 2007 11:45:49 -0800, Sean Kelly <sean f4.ca> wrote:
 
 Matthias Thurau wrote:
 "If the objects are no longer referenced, the GC will destroy those also."

 Thats exact the case: In my example the GC isn t destroying that unreferenced
member.
Technically, it is. It's just not destroying it in the collection immediately following the object's allocation, which isn't guaranteed anyway. As I said previously, it's likely that a register still holds the address of this object when the allocation is triggered, because basically nothing happens between the object's construction and the collection. In a real application, such things are unlikely occur.
  ~this()   {   writefln("Destructor %d", myNumber); }
To help the GC, is Java-like null assignment necessary? The following line helps std.gc.fullCollect() to destroy My2Class members. ~this() { writefln("Destructor %d", myNumber); member = null; }
Not usually. The problem is this case is a register with the value, not a memory location. I've run into it before when trying to create simple unit tests and demos in D. The easiest way around it that I've found is to construct an additional "throw away" object after the object you expect to be cleaned up, to overwrite any lingering register data that may still point to the old object. This is handy for tiny test apps, but again, I don't think anything needs to be done for real apps. Sean
Dec 18 2007
parent reply Matthias Thurau <Matthiasth gmx.de> writes:
"The problem is this case is a register with the value, not
a memory location"

I don t understand what a register is :( Could you give me an example? And
maybe Your workaround for that?

greetings
Dec 19 2007
parent reply guslay <guslay gmail.com> writes:
Matthias Thurau Wrote:

 "The problem is this case is a register with the value, not
 a memory location"
 
 I don t understand what a register is :( Could you give me an example? And
maybe Your workaround for that?
 
 greetings
A register is a small storage available to the cpu to make computation. http://en.wikipedia.org/wiki/Processor_register However I doubt that Sean's assumption is valid in this case. I've modified the original testcase to call { MyClass A = new MyClass(); } up to a couple tens of THOUSAND times. Whereas the scoped class is destroyed on scope exit, the destructor of the embedded object is only called at program termination (as described). Collect as no effect on them, no matter how many instances are created. That would be a lot of registers! Some other things I have noticed: * Without scope attribute, all instances of both classes are destroyed on collect. No problem. * With the scope attribute, embedded instances are destroyed in reverse order of creation, by group of 256. Sub_Destructor2 255 ... Sub_Destructor2 0 Sub_Destructor2 511 ... Sub_Destructor2 256 .. This GC behavior is stranger than usual... (using Phobos.)
Dec 19 2007
parent reply Sean Kelly <sean f4.ca> writes:
guslay wrote:
 Matthias Thurau Wrote:
 
 "The problem is this case is a register with the value, not
 a memory location"

 I don t understand what a register is :( Could you give me an example? And
maybe Your workaround for that?

 greetings
A register is a small storage available to the cpu to make computation. http://en.wikipedia.org/wiki/Processor_register However I doubt that Sean's assumption is valid in this case. I've modified the original testcase to call { MyClass A = new MyClass(); } up to a couple tens of THOUSAND times. Whereas the scoped class is destroyed on scope exit, the destructor of the embedded object is only called at program termination (as described). Collect as no effect on them, no matter how many instances are created.
Oops. My comment about registers referred to the GC not collecting the most recently constructed object which simply went out of scope. Objects created with the "scope" attribute are entirely different. In that case, the "scope" object is deleted when scope exits, but no objects it references are deleted. This is by design, and I addressed it in another post in this thread. Sean
Dec 19 2007
parent reply Jason House <jason.james.house gmail.com> writes:
Sean Kelly Wrote:

 guslay wrote:
 However I doubt that Sean's assumption is valid in this case. I've modified
the original testcase to call
 
 { MyClass A =    new MyClass(); }
 
 up to a couple tens of THOUSAND times.
 
 Whereas the scoped class is destroyed on scope exit, the destructor of the
embedded object is only called at program termination (as described). Collect as
 no effect on them, no matter how many instances are created.
Oops. My comment about registers referred to the GC not collecting the most recently constructed object which simply went out of scope. Objects created with the "scope" attribute are entirely different. In that case, the "scope" object is deleted when scope exits, but no objects it references are deleted. This is by design, and I addressed it in another post in this thread.
I think that the point of the original post is getting lost. After having scope variable(s) go out of focus (and get deallocated), a call to full collect is done. The issue was that full collect did not collect the objects allocated by the scope objects, even though there was no references to them.
Dec 19 2007
parent Sean Kelly <sean f4.ca> writes:
Jason House wrote:
 Sean Kelly Wrote:
 
 guslay wrote:
 However I doubt that Sean's assumption is valid in this case. I've modified
the original testcase to call

 { MyClass A =    new MyClass(); }

 up to a couple tens of THOUSAND times.

 Whereas the scoped class is destroyed on scope exit, the destructor of the
embedded object is only called at program termination (as described). Collect as
 no effect on them, no matter how many instances are created.
Oops. My comment about registers referred to the GC not collecting the most recently constructed object which simply went out of scope. Objects created with the "scope" attribute are entirely different. In that case, the "scope" object is deleted when scope exits, but no objects it references are deleted. This is by design, and I addressed it in another post in this thread.
I think that the point of the original post is getting lost. After having scope variable(s) go out of focus (and get deallocated), a call to full collect is done. The issue was that full collect did not collect the objects allocated by the scope objects, even though there was no references to them.
Right. This related to my comment about registers above. Sean
Dec 19 2007
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Steven Schveighoffer Wrote:

 "Jason House" wrote
 I haven't tried this, but is it possible to declare class member variables 
 as scope so that they will get deleted when the rest of the object does? 
 This could save coding of custom destructors in some cases.
Custom destructors should NEVER destroy other GC allocated objects. the GC cannot guarantee the order of collection, meaning if you have a pointer to another GC allocated object, that object may have already been collected. There is no real reason to delete other objects in a destructor. If the objects are no longer referenced, the GC will destroy those also. The only things you should destroy in a destructor are non-GC allocated resources, such as file descriptors, or memory allocated with C's malloc. So to answer your question: scope is not necessary as a modifier for a member variable.
I wasn't asking about necessary. I was asking if it's valid. It's easy enough to construct RAII-like examples where a timely destruction of a member variable would be handy. It can also be handy when standard GC operation is overridden.
Dec 18 2007
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jason House" wrote
 Steven Schveighoffer Wrote:

 "Jason House" wrote
 I haven't tried this, but is it possible to declare class member 
 variables
 as scope so that they will get deleted when the rest of the object 
 does?
 This could save coding of custom destructors in some cases.
Custom destructors should NEVER destroy other GC allocated objects. the GC cannot guarantee the order of collection, meaning if you have a pointer to another GC allocated object, that object may have already been collected. There is no real reason to delete other objects in a destructor. If the objects are no longer referenced, the GC will destroy those also. The only things you should destroy in a destructor are non-GC allocated resources, such as file descriptors, or memory allocated with C's malloc. So to answer your question: scope is not necessary as a modifier for a member variable.
I wasn't asking about necessary. I was asking if it's valid. It's easy enough to construct RAII-like examples where a timely destruction of a member variable would be handy. It can also be handy when standard GC operation is overridden.
Not neccessary == not implemented :) Why implement a feature that is not needed? I guess I should have stated that. From the attributes page (http://www.digitalmars.com/d/attribute.html): "scope cannot be applied to globals, statics, data members, ref or out parameters." Timely destruction of a member that is not referenced in any other object/thread should occur when the object that owns the member is destroyed. No need to force it, which is why scope isn't necessary or valid. -Steve
Dec 18 2007