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.

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.