current GC behavior
luka8088
luka8088 at owave.net
Tue Nov 6 13:05:32 PST 2012
On 6.11.2012 21:59, Ali Çehreli wrote:
> On 11/06/2012 12:00 PM, luka8088 wrote:
>
> > Yes, but it seems that we can in general say that the following code
> > will never fail... or am I wrong ?
> >
> > import core.memory;
> >
> > class a {
> > static int totalRefCount = 0;
> > this () { totalRefCount++; }
> > ~this () { totalRefCount--; }
> > }
> >
> > void main () {
> > assert(a.totalRefCount == 0);
> > ({
> > auto a1 = new a();
> > assert(a.totalRefCount == 1);
> > })();
> > GC.collect();
>
> The current definition of GC.collect() explicitly says that its
> definition may change:
>
> http://dlang.org/phobos/core_memory.html#collect
>
> "the meaning of this may change based on the garbage collector
> implementation".
>
> > assert(a.totalRefCount == 0);
> > }
> >
> >>
> >> In fact, some objects may never be collected even if there are no more
> >> references to them.
> >
> > Can you give me an example ?
>
> I can't come up with an example but the spec is clear on that issue:
>
> http://dlang.org/class.html#destructors
>
> "The garbage collector is not guaranteed to run the destructor for all
> unreferenced objects. Furthermore, the order in which the garbage
> collector calls destructors for unreference objects is not specified.
> This means that when the garbage collector calls a destructor for an
> object of a class that has members that are references to garbage
> collected objects, those references may no longer be valid. This means
> that destructors cannot reference sub objects."
>
> Ali
>
I see, so is there some alternative for memory leak tests ?
Luka
More information about the Digitalmars-d-learn
mailing list