harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Date Tue, 24 Oct 2006 15:52:33 GMT
Gregory Shimansky wrote:
> On Tuesday 24 October 2006 19:20 Salikh Zakirov wrote:
>> I would like to request for comments on a possible way of getting rid
>> of java execution from vm_hint_finalize(). The initial patch is attached to
>> HARMONY-1952.
> You've also modified the problematic test in it. Are you sure this 
> modification doesn't change the test behavior in any way? Wouldn't it be 
> better to check that original test works well with it?

The original test may not work with the modification. I consider this a bug in the test.
It implicitly assumed that all cleared references will be available in reference queue
as soon as System.gc() completes. This was true before.

The patch in HARMONY-1952 breaks this, because references are enqueued from the context
of finalization thread, and this may happen some time later.

As the specification does not say at what exact moment cleared references should
become available, I suppose that changing one implementation assumption
("references are available after System.gc()") to a weaker assumption
("references are available after System.gc();System.runFinalization()") is
a correct thing to do.

> Hmm... what if jthread_monitor_try_enter(finalizer_thread) fails, that is, 
> monitor is owned by another thread? Is the lock global for all finalization 
> threads? It won't give good results if there is more than one of them.

Yes, the lock is global. I used try_enter() to prevent possible deadlock scenario,
when the finalization happens at precisely the moment finalization thread is holding
the finalization lock. If this happens, and vm_hint_finalize() cannot grab
the finalization monitor, no harm is taken, because locked finalization monitor
means that the finalization thread is active, and does not need to be waked up.

On the other hand, the finalization queue itself is protected by a different native
lock, which is guaranteed not to be locked at the garbage collection time
(because it is locked and unlocked in suspend-disabled region).
(* okay, I didn't check this, but I believe it should work this way *)

> Other than that I think your approach with notifying finalizer threads instead 
> of running the code on the same stack is better.

Let's wait for other potential problems to be found by other Harmony contributors :)
In any case, it will take some time to bring this idea to a committable patch.

View raw message