harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable
Date Wed, 11 Oct 2006 00:19:56 GMT
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.

Thanks,
xiaofeng

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


Mime
View raw message