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]
