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

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

Yes, the garbage collector is temporarily disabled by design.  Now, it would
be wonderful if we could not disable the GC at any point, so if you have
some suggestions based on the points below, lets discuss them.  I will say
that garbage collection can get complicated though.

First, I would recommend in general, whether using XMLVM or not, to reduce
the number of finalizers to as small as possible.  Finalizers cause a lot of
overhead & there is no guarantee when they are invoked.  That is true in a
normal JVM as well.

Now to the issue at hand: yes, the GC is multi-threaded (single threading
the GC causes other undesirable issues such as deadlocks & performance
issues).  So when it is determined there are finalizers to run (call this
thread 1), the GC is disabled & the separate thread (call this thread 2) is
notified to run the finalizers.  If the GC were not disabled, thread 1 would
then garbage collect the instances likely before thread 2 had a chance to
run the finalizers.  And you'd get an EXC_BAD_ACCESS error.  As it is,
thread 2 will reenable the GC once there are NO finalizers left to run.
That usually means garbage collection has to wait until the next pass & hope
there's not more finalizers temporarily blocking GC.

So if every instance had a finalizer, the GC would never get a break to
clean up.

I agree this is not ideal & would prefer a better solution, but this is what
we have for now.  We use the Boehm GC & part of this solution is due to our
understanding of the Boehm GC.  Perhaps there is something available in the
Boehm GC to do this better?

Thanks,
Paul


On Mon, Oct 17, 2011 at 11:08 AM, Shai <sha...@ya...> wrote:

> Hi Guys,
> I've been banging my head against this memory leak issue for the past
> couple of weeks trying to resolve it and hopefully you guys can help me
> understand it.
>
> My code which is mostly native iPhone code, uses two threads: main and
> logical.
> I have quite allot of native objects allocated (large image objects) but I
> clear them all up in the finalizer code on the java side (the java object
> has a "pointer" and when the finalizer is invoked a native method cleans up
> the pointer).
>
> However, it seems the finalizers are only invoked occasionally. This
> effectively causes all the RAM to run out practically immediately and for
> some reason xcode's Instruments seems to be completely useless against this
> particular leak.
>
> Debugging the GC it seems to be working as expected and never increases
> above 3mb total heap (which makes sense for the app) but the free mem eats
> up the 128mb pretty quickly.
>
> Looking at FinalizerNotifier.java I see that the code uses a finalizerMutex
> which disables the GC, however since I have a separate thread which keeps
> allocating data and doesn't synchronize against this mutex won't that pose a
> problem?
>
>
> Thanks.
> Shai.
>
>
> ------------------------------------------------------------------------------
> 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
>
>