On 10/12/06, Pavel Pervov <[EMAIL PROTECTED]> 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 <[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
>
--
Mikhail Fursov
