Mikhail, The problem is not in locking any resources (Alexey Varlamov discovered another error - in kernel classes natives). The problem is in recursive loading of the same class twice. Yes, lazy (interpreter style) resolution will solve the problem - JIT will never ask to load classes while compiling.
I'll try to prepare such test. But it will take some time. I'll file JIRA and then get back to this thread with its number. Regards, Pavel. On 10/12/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
I'm glad to hear this part of the problem is resolved :) Some thoughts for the initial test from Pavel: We do really need the Java test to discuss. I still think that the problem you desribe is not a JIT problem. Yes, both JET and OPT ask to resolve classes during compilation. When they do it there are no native resources locked. You said that the lazy resolution will help. I see no difference. Does it matter if you go into recursion with a lazy resolution helper in runtime of with a recursive compilation? On 10/12/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > > > > > > > > > > > > -- Mikhail Fursov
