Yes, I am. :) The common rule of not executing Java under native lock applies to JNI too.
Regards, Pavel. On 10/12/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
12.10.06, Pavel Pervov<[EMAIL PROTECTED]> написал(а): > Alexey, > > The main issue here is why classloading (?) calls to GC under native lock. > All the rest is just a consequences. > Could you, please, show the point (file:line) where gc_alloc is called under > lock? Oh, probably you are right. The faulty method is Java_java_lang_VMClassRegistry_getSystemPackages() vm\vmcore\src\kernel_classes\native\java_lang_VMClassRegistry.cpp 389-414 Will fix. -- Alexey > > Thanks, > Pavel. > > On 10/12/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > > Guys, > > > > I've found another deadlock scenario recently, see HARMONY-1833 [1]: > > > > "deadlocks happening between main thread (MT) and finalizer thread (FT): > > 1) MT performs classloading, it grabs ClassLoader::_lock; > > 2) GC happens, FinalizerThread.startFinalization() is called, FT > > activates; > > 3) FT invokes some finalize() method, compilation starts and grabs > > g_compileLock; > > 4) FT waits for ClassLoader::_lock to allocate code_chunk_info; > > 5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads() > > and waits for g_compileLock; > > > > I believe this scenario can be fixed via separating locks for > > classloading and loader-pool allocations." > > > > [1] http://issues.apache.org/jira/browse/HARMONY-1833 > > > > -- > > Alexey > > > > 12.10.06, Gregory Shimansky<[EMAIL PROTECTED]> написал(а): > > > On Wednesday 11 October 2006 16:15 Pavel Pervov wrote: > > > > (Branching from original thread as this is different problem than in > > the > > > > root message.) > > > > > > Wasn't it the same problem, just happening on classlib initialization? I > > think > > > the scenario is the same. > > > > > > > The following scenario will fail: > > > > > > > > 1) JIT compiles some method and resolves some class "A" through user > > > > defined class loader > > > > 2) user define class loader loads class "A" and triggers compilation > > of > > > > some of its methods > > > > 3) this method happens to depend on class "A", and, thus, JIT resolves > > the > > > > class "A" through the same class loader > > > > > > > > Voila! We have the described situation. > > > > > > A synthetic test for drlvm could really help to emphasize the problem. > > Then we > > > can run this test on all other VMs with possible modifications. BTW > > sun's > > > hotspot should compile a method if it is called several times, so user > > > defined class loader could do something like calling this method many > > times > > > to trigger its compilation. > > > > > > -- > > > Gregory Shimansky, Intel Middleware Products Division > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >
