want your help

[Yongqiang Yang]

Hi David Holmes,

Thank you very much.

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++.

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.

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>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>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101209/921b4c59/attachment.html