want your help
Y. Srinivas Ramakrishna
y.s.ramakrishna at oracle.com
Thu Dec 9 12:42:00 PST 2010
Yongqiang, In addition to the suggestions already made,
you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC -XX:+VerifyAfterGC to
see if it sheds more light in the issue. (although these might
slow down execution and cause a race/bug to disappear.)
best.
-- ramki
On 12/9/2010 5:55 AM, Yongqiang Yang wrote:
> Hi David,
>
> Xint works well. I think I did something wrong with finalizer, but I
> can't find it.
> When in Xcomp mode, finalize function is not called before object was collected.
> I am sure finalizer is registered.
>
> On Thu, Dec 9, 2010 at 3:06 PM, David Holmes<David.Holmes at oracle.com> wrote:
>> 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
>>>
>>
>
>
>
More information about the hotspot-dev
mailing list