dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [DotGNU]Finalization


From: Thong \(Tum\) Nguyen
Subject: RE: [DotGNU]Finalization
Date: Tue, 1 Jul 2003 07:12:09 +1200

Good news.  I tracked down the cause of this finalization problem.

The reason we weren't seeing this earlier is because of a layout problem
(see patch 1676) causing some classes to be "randomly" marked as
mananaged or unmanaged.  

It turns out the small layout bug was causing all objects to be marked
as "managed" except for the last one.  The last object was then
allocated using AllocAtomic rather than Alloc and AllocAtomic (unlike
Alloc) doesn't register object finalizers.  Making AllocAtomic register
finalizers (along with the layout patch) appears to have solved the
problems.  All objects are now getting finalized :D.

^Tum


> -----Original Message-----
> From: Rhys Weatherley [mailto:address@hidden
> Sent: Sunday, 22 June 2003 10:04 p.m.
> To: Thong (Tum) Nguyen; address@hidden
> Subject: Re: [DotGNU]Finalization
> 
> On Sunday 22 June 2003 07:52 pm, Thong \(Tum\) Nguyen wrote:
> 
> >         public static void Main()
> >         {
> >                 new Pok();
> >                 new Pok();
> >                 new Pok();
> >
> >                 GC.Collect();
> >                 GC.WaitForPendingFinalizers();
> >         }
> > }
> >
> > It should print out "finalized!" thrice but it only prints it out
once.
> > It looks like the first (and only the first) finalizable object is
never
> > finalized.
> 
> It's possible that the pointer to one of the objects is still stored
somewhere
> in the stack when the GC run happens.  It will get picked up as "still
in
> use" by the conservative collector.  It will only get collected if the
> pointer is overwritten somehow.
> 
> Because there are three calls to "new Pok()", the second and third
will
> overwrite the temporary storage used by the first and second.  This
will
> leave a pointer to the third still in play, and hence uncollectable
until
> something else stomps on it.
> 
> Welcome to the wonderful world of conservative garbage collection. :-)
> 
> We probably can't do anything about this for explict calls to the
collector,
> but we may be able to do something for the shutdown run in
> ILExecProcessDestroy.
> 
> Prior to calling the collector for the last time, clear all of the CVM
thread
> stacks to zero.  This will remove any transistory pointers and allow
them to
> be collected.  Some experimentation is probably required to find the
right
> balance - I doubt you'll be able to collect everything.
> 
> > PS.  I have monitors working and finalizers are now running on a
> > separate thread :D.
> 
> Fantastic!
> 
> Cheers,
> 
> Rhys.
> 
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]