Re[2]: [Gc] Patches resubmission 7

Ivan Maidanski ivmai at mail.ru
Sat Jun 13 06:48:32 PDT 2009


Hi!

"Boehm, Hans" <hans.boehm at hp.com> wrote:
> Thanks.
> 
> I'm committing this, with a change to your GC_finalize_all() fix.
> 
> I expect that JVMs using this will not expect finalizers to be run in this thread.  It's unclear to me whether this will break things, but I'd rather keep the semantics roughly what they were, especially since this is all part of a hopelessly broken interface anyway, and we aren't really going to fix it.  It should only be used to implement JVM functionality that Java deprecated ten years ago, for excellent reasons.
> 
> I fixed the corresponding comment in javaxfc.h.  (I agree with all your reasons that it was broken.)
> 
> Hans

You've added your code but forget to remove my GC_invoke_finalizers() call
in GC_finalize_all() (and to remove the entry from ChangeLog).

Your code is a bit better than before although it looks like:

  while (have_finalizers) {
     enqueue_if_any(); // typically a NOP
     notify();
  }

So, this thread just does busy waiting.

The better (and compliant with the JVMs) code could be:

  while (have_finalizers) {
     enqueue_if_any();
     notify();
     if (!have_finalizers) wait_for_invoke_finalizers_completed();
  }

Or, better, I think, let this be the responsibility of GC_finalize_all() users to have wait_for_invoke_finalizers_completed() in their client notify() procs.

PS. Tip for JVM implementers: the best way of dealing with GC_finalize_all() (according to java.lang.ref.Finalizer code) is to fork a thread which executes GC_set_finalize_on_demand(0) and GC_finalize_all().

Bye.



More information about the Gc mailing list