[squeak-dev] Priority of WeakArray finalizationProcess

Levente Uzonyi leves at elte.hu
Tue Jun 15 11:09:45 UTC 2010

On Tue, 15 Jun 2010, Joachim Geidel wrote:

> Levente,
> Thanks a lot for analyzing this! I think I should have a more thorough look
> at all those Semaphores and Mutexes in JNIPort. Maybe some of them can be
> eliminated, which would also be better for performance.
> 2.9 seconds sound good even though in VisualWorks it's in the sub-second
> range. OTOH, the JVM is started just once when an application runs, and I
> have some optimizations ready for the final release of JNIPort.

If Igor's new finalization mechanism will be integrated (in 4.2), then it 
will be possible to cut 0.3 seconds down from the runtime. I also expect 
that in 1-2 years we will have an inlining JIT available which could get 
the execution time into the sub-second range.


> Thanks again
> Joachim
> Am 14.06.10 22:06 schrieb Levente Uzonyi:
>> So the user process entered the mutex of the JVM and it's trying to enter
>> the WeakRegistry's semaphore, while the finalization process entered the
>> WeakRegistry's semaphore and it's trying to enter the JVM's mutex.
>> (The mutex's owner was is not nil when the deadlock happens, because the
>> code enters the mutex more than once, so that's normal.)
>> This deadlock doesn't happen in Pharo, because it uses the old
>> WeakRegistry >> #finalizeValues implementation which does the actual
>> finalization outside the critical section. I will soon upload a version of
>> the Collections package to the Inbox which does the same. With this code
>> it took 2.9 seconds to start the JVM on my notebook.

More information about the Squeak-dev mailing list