harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Date Thu, 12 Oct 2006 10:06:41 GMT
On 10/12/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
>
> Yes, lazy (interpreter style) resolution will solve the problem - JIT will
> never ask to load classes while compiling.


Here we have different vision. What do you think, is it possible to go into
the endless resursion with lazy resolution?

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.


Ok, so we can discuss the problem in details. Special thanks to Ivan Popov -
now I know the magic -Xcomp option :)

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
> >
>



-- 
Mikhail Fursov
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message