Re: [xmlvm-dev] Finalization, threading and memory leak

[Paul P. <bay...@gm...>]

Consider the example below.  If we invoked the finalize() in the same
thread, it would deadlock & unfortunately can't be blamed on poor
application code since it's unrelated/unpredictable.  If both threads are
attempting to "do stuff" at the same time, it would deadlock.  That's one
reason the finalize() invocation occurs in a different thread, but if we
could do collection in that same finalizer thread, that would be nice.

Thread 1:
    synchronized (obj1) {
        synchronized (obj2) {
            // do stuff
        }
    }

Thread 2:
    synchronized (obj2) {
        new Object(); // "new" causes a finalize() invocation on the
instance below
    }

A different instance which is ready for finalization:
    protected void finalize() {
        synchronized (obj1) {
            // do stuff
        }
    }

Thanks,
Paul



On Mon, Oct 17, 2011 at 2:01 PM, Shai <sha...@ya...> wrote:

> I don't think I know much on the subject, I've ported VM's but usually
> treated the GC as a "black box" sort of thing. This past week I did some
> digging in the code (trying to pinpoint the issue) and that's the source of
> most of my understanding in Boehm.
>
> The issue of a deadlock or problem in a finalizer is probably the mistake
> of the finalizer author, many VM's fail for this use case. This can pose a
> problem for cases such as a finalizer trying to close a stream which might
> call flush() hence causing a delay or even failure. But that use case would
> probably be problematic with every VM.
>
> Looking at it I find the code a bit hard to follow and I'm not exactly sure
> its properly configured for threading to begin with. E.g. for thread support
> GC_stop_world() needs to be defined via GC_set_stop_func() (there is such a
> method in the pthread version but no one is invoking it).
> Anyway, if the world would be stopped during GC it might actually improve
> the performance and fix some of the issues you were seeing in the past. Or
> am I missing something here?
>
> I don't think there would be a major difference between invoking directly
> from the no-order method you are currently using and the method I suggested
> (it just seemed more appropriate since its designed for Java.
> I don't know how to determine the GC thread as the finalizer thread but I
> think setting the finalizer to invoke directly will solve this issue just as
> well.
>
> Thanks.
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>