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

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

P.S. I misread it before.  I thought you were referring to
GC_finalizer_notifier & that's what I meant to type.  We currently use
GC_REGISTER_FINALIZER_NO_ORDER.

Paul

On Mon, Oct 17, 2011 at 12:59 PM, Paul Poley <bay...@gm...> wrote:

> 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
>>
>
>