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.
Especially, if you hold VM internal lock.
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]
> > > >
> > > >
> > >
> >
>
