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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
