want your help

[David Holmes]

-Xcomp compiles every method on first use, rather than only compiling 
when the method becomes "hot".

If the test passes in -Xmixed but not -Xcomp then it is likely that in 
-Xmixed the problematic code is not getting compiled. (Use 
-XX:+PrintCompilation to check - may need a debug VM for that).

The jobject is an opaque reference to the object for which finalize() is 
to be invoked. Even if safepoints occur and GC occurs etc, this should 
remain a valid reference. If that is not the case then something is 
corrupting the value. The stacktrace from the assert should show where 
the corruption is detected, which may help, but it won't show where it 
occurred. It could be something as simple as not setting up the correct 
register usage for return from the native method - ie your method return 
from GetObjectClass might be trashing the register that holds "ob". I 
think you would need to be able to dump dissassenbly of both methods to 
see if there is obvious corruption.

David Holmes

Yongqiang Yang said the following on 12/09/10 11:57:
> Hi Gary,
> 
> 
> That you for your help very much.
>  
> I have looked as you suggested.  There is no safepoint rom return at 
> GetObjectClass to calling CallVoidMethod. 
> 
> This bug  appears in Finalizer thread every time. Thus, I think maybe 
> there is a bug in finalizer.  When I use -Xcomp option, finalize 
> function is not called.  When I 
> use mixed or interpretered jvm, finalize is called.  I don't know what 
> happens in -Xcomp mode.  I  find that finalizer  is registered using 
> -XX:+TraceRegisterdFinalizer.
> 
> 
> On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson <gbenson at redhat.com 
> <mailto:gbenson at redhat.com>> wrote:
> 
>     Hi Yongqiang,
> 
>     Yongqiang Yang wrote:
>      > Hi everyone,
>      >
>      > I am porting hotspot to MIPS.  I meet a bug as follows.
>      >
>      > In function Java_java_lang_ref_Finalizer_invokeFinalizeMethod,
>      > value of jobject is right when call GetObjectClass and also right
>      > before return from GetObjectClass . However,  it is wrong when
>      > calling CallVoidMethod.   For example, It is changed from 0x3e0885d0
>      > to 0x423ce794.
>      > Thus, it results in an assert failure below.
>      >
>     ----------------------------------------------------------------------
>      >   assert(SharedSkipVerify || obj->is_oop()) failed: sanity check
>      >
>     ----------------------------------------------------------------------
>      >
> 
>      > I want to know who will change this value from return at
>     GetObjectClass
>      > to calling CallVoidMethod.  During this time, GC don't run.
> 
>      >
>      > Could anyone have an idea about this?
> 
>     Look at the source code to jni_GetMethodID and jni_CallVoidMethod,
>     in hotspot/src/share/vm/prims/jni.cpp.  Notice the JNI_ENTRY and
>     JNI_END surrounding them?  Look at the source code for JNI_ENTRY,
>     in hotspot/src/share/vm/runtime/interfaceSupport.hpp.  Do you see
>     the ThreadInVMfromNative?  That object has a constructor and a
>     destructor, both of which contain thread state transitions.
>     Safepoints can occur during those transitions, and oops can change
>     at any safepoint regardless of whether the GC runs.  You could try
>     running with -XX:+TraceSafepoint or something like that to see if
>     one is occuring.
> 
>     Cheers,
>     Gary
> 
>     --
>     http://gbenson.net/
> 
> 
> 
> 
> -- 
> Best Wishes
> Yongqiang Yang
>