want your help
Yongqiang Yang
xiaoqiangnk at gmail.com
Thu Dec 9 05:55:38 PST 2010
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
>>
>
--
Best Wishes
Yongqiang Yang
More information about the hotspot-dev
mailing list