harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Date Thu, 12 Oct 2006 09:39:14 GMT
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 <mike.fursov@gmail.com> 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 <pmcfirst@gmail.com> 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 <alexey.v.varlamov@gmail.com> wrote:
> > >
> > > 12.10.06, Pavel Pervov<pmcfirst@gmail.com> написал(а):
> > > > 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 <alexey.v.varlamov@gmail.com> 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<gshimansky@gmail.com> написал(а):
> > > > > > 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:
> > harmony-dev-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail:
> > > harmony-dev-help@incubator.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Mikhail Fursov
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message