want your help

[David Holmes]

Hi,

Yongqiang Yang said the following on 12/09/10 16:44:
> Maybe I didn't elaborate the problem clearly.  
> Java_java_lang_ref_Finalizer_invokeFinalizeMethod is  a native method. 
>  It invokes GetObjectClass and CallVoidMethod.   So jump 
> to Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native 
> wrapper.  Thus returns  from it uses a native return wrapper.   Callings 
> or returns of GetObjectClass and CallVoidMethod are done by g++.

Sorry - You said you were porting to MIPS so I was pointing out that the 
problem might be in the MIPS code that handles native method calls eg by 
clobbering a register that might be used in the callee. But I just 
realized that is for calls from Java to native, not from native to Java 
- the latter is all basic C++ code as you point out.

> The bug is as follows.
> Before return from GetObjectClass, the ob's value is right,  that it 
> references a right object.  However, when CallVoidMethod begins,  ob 
> references a invalid object.  

Are you certain there is no gc occurring? If not, and the ob value has 
changed when GetObjectClass returns then I can only assume some kind of 
memory stomp during the execution of GetObjectClass. Can you add some 
extra local variables and check their values to see if it is a stack stomp?

Does the problem occur with -Xint? Is compilation occurring elsewhere?

David
-----

> 
> During the change, Finalizer-Thread is in native 
> method Java_java_lang_ref_Finalizer_invokeFinalizeMethod.  That 
> says Finalizer-Thread runs codes compiled by g++ during the change.
> 
> I think another thread changes ob's value, but I can't think of any 
> thread except GC.
> 
> 
> 
> On Thu, Dec 9, 2010 at 10:27 AM, David Holmes <David.Holmes at oracle.com 
> <mailto:David.Holmes at oracle.com>> wrote:
> 
>     -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> <mailto: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
> 
> 
> 
> 
> -- 
> Best Wishes
> Yongqiang Yang
>