harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable
Date Wed, 11 Oct 2006 01:14:11 GMT
On Wednesday 11 October 2006 04:19 Xiao-Feng Li wrote:
> Yes, I agree.
>
> This is related to the issue I found in bootstrapping JVM. Since DRLVM
> is largely written in C (C++) and partially written in Java, the
> bootstrapping process should be more clearly to avoid this kind of
> bug. That is all the system level code that are written in Java
> probably can be precompiled during bootstrapping. So Gregory, I think
> the precompilation as not of a workaround, but of a correct solution.
>
> :-)
>
> And another way is to avoid some core part of the JVM written in Java.
> We are writing a finalization implementation in C for GCv5. Probably
> that will help to reduce related bugs.
>
> Basically we need a clear understanding in mind about which part is
> belongs to the minimal core part of the JVM, which are not.
>
> JikesRVM (and Moxie) does bootstrapping in a pre-run of the JVM in a
> host JVM to generate its startup image. With C, we don't need this
> step, while we should be clear about the logic in bootstrapping.

The reason why I called it a workaround is because the history of running Java 
code from JIT has a lot of discovered bugs and so far there were only 
workarounds for it. The one "killer" argument not to do this escapes from my 
memory, maybe Pavel remembers it. I seem to recall there was one but it is 
very late at night and I should better go to sleep right now.

The general fix for all these kind of troubles would be lazy resolution when 
JIT does not resolve anything but inserts resolution code inside of compiled 
methods to do it at runtime.

> On 10/11/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > On Monday 09 October 2006 21:01 Pavel Pervov wrote:
> > > Geir, all,
> > > I did reserched this failure some time ago. The same failure was
> > > observed on gc.Finalizers.
> > > Here is what I've found.
> > >
> > > Now what is happening:
> > > 1)       FinalizerThread is being run
> > > 2)       java/lang/Object.notify()V is being compiled
> > > 3)       java/lang/InternalError is being resolved (and loaded) for
> > > java/lang/Object
> > > 4)       GC happens while creating instance of java/lang/Class for
> > > java/lang/InternalError
> > > 5)       vm_hint_finalize happens
> > > 6)       java/lang/ref/ReferenceQueue.enqueue is being called
> > > 7)       java/lang/Object.notify()V is being compiled
> > > 8)       java/lang/InternalError is being resolved (and loaded) for
> > > java/lang/Object
> > > 9)       ClassCircularityError occurs for java/lang/InternalError
> > > 10)   VM returns to step (3)
> > > 11)   Assertion happens in SuccessLoadingClass for
> > > java/lang/InternalError as LoadingClass instance for this class was
> > > removed on step (9)
> > >
> > > It can be tried to fix it in class loading, but I can imagine only one
> > > generic solution for this problem: do not run Java while compiling.
> > > Which more specifically means no Java heap allocations as our
> > > finalization subsystem is partially written in Java.
> > > Whole native stack on Windows look the following way:
> >
> > Your finding reveals quite a deep design bug in VM. I can imagine another
> > workaround for this, like compiling some kernel class methods manually
> > (like we preload kernel classes manually) on initialization, like
> > j.l.Object.Notify. But still it is not a general solution for this
> > problem, just a workaround.
> >
> > --
> > 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
>
> ---------------------------------------------------------------------
> 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

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


Mime
View raw message