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]
