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

[Arno P. <ar...@pu...>]

right now we use GC_register_finalizer_no_order() because otherwise 
there would be cycles in objects that have a finalizer (which is common 
in Java). If you are interested in the details, read the section of 
topological ordering:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html

The method you suggested (GC_register_finalizer_unreachable()) is an 
optimization but potentially introduces finalizer cycles again. I don't 
see a way how the code generating backend can distinguish when to use 
GC_register_finalizer_unreachable() and when to use 
GC_register_finalizer_no_order().

Arno


On 10/17/11 10:10 AM, Shai 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