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

[Shai <sha...@ya...>]

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.