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

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

It sounds like you know what you're talking about, so forgive me if I state
the obvious.

For our discussion, there are 3 types of threads:

   1. GC thread - created by Boehm code
   2. Finalizer thread - created by XMLVM
   3. All application threads

So any cross-compiled Java code besides that invoked from a finalize() will
occur in thread type #3.

Currently, the actual garbage collection is also done in thread type #3.
Every time memory is allocated, it is a chance for the GC to run in that
same thread.  I.e. That thread will first invoke the finalizer notifier and
then run the GC.

In our case, the finalizer notifier temporarily disables collection &
broadcasts a message to our finalizer thread to begin finalizations in the
thread of type #2.  Aside from performance, if the finalize() invocations
were done in the same thread instead of broadcasting to the other thread,
deadlocks can occur. I.e. Consider a synchronized block in a finalize()
method that could be invoked any time you dared use the "new" keyword.

That to say, if we could move the garbage collection to the same thread as
the finalization (not of thread type #3) so that we didn't have to disable
collection at any point, that would be ideal. Right now I'm at the mercy of
the community for their expertise with the Boehm GC.

I have only used GC_finalizer_notifier and not
GC_register_finalizer_unreachable so far.  Could you explain the difference?

This is good discussion to have, especially since all iOS instances have
finalize() methods to release the Obj-C counterpart. Thanks,
Paul


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

> Thanks,
> I don't have a choice about using finallizers since I'm porting an existing
> API and the complexity of monitoring object lifecycle will make the API
> considerably more complex (not to mention break existing 3rd party code).
>
> Finalizers have the drawback of "double cycle" gc, but for this particular
> case I don't see another option. E.g. they are used within Java for stream
> closing and component/image peer disposal. Since IO streams have a finalizer
> and must always be used from a separate thread I'm guessing I'm not the only
> one who runs into this problem, its probably worse for my case though.
>
>
> The best solution would have beein invoking the finalizers on the GC
> thread, but since you say the performance is prohibitive (I'm already
> struggling with performance here) this isn't an option.
>
>
> Java itself doesn't handle the use case of every object having a finalizer
> well (which isn't my case at all) since it performs finalization instead of
> collection and only collects in the next cycle.
>
> I don't quite understand why GC_register_finalizer_unreachable can't be
> used to register a function that invokes the finalizer directly?
>
>
> ------------------------------------------------------------------------------
> 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
>