want your help
Yongqiang Yang
xiaoqiangnk at gmail.com
Thu Dec 9 17:49:27 PST 2010
Hi ramki,
Thank you for your help.
I have done as you suggested and found nothing different. I list my
test program and output at end of this email.
Apparentlym, object at 0x2dfa0000 was collected before finalized with
Xcomp. However, with Xint, everything is right. Both Xcomp and Xint
register finalizer through the same function
instanceKlass::register_finalizer, where a handle for object is
constructed.
Yongqiang.
My test program named finalexc.java is as follows.
public class finalexc {
static int f;
public void finalize() {
f++;
System.out.println("finalize " + f);
}
static void test() {
for (int i = 0; i < 100; i++) {
new finalexc();
System.gc();
}
}
public static void main(String av[]) {
while(true) test();
}
}
java -Xcomp -XX:+TraceFinalizerRegistration finalexc
Output is as follow.
===========================================================
VM option '+TraceFinalizerRegistration'
Registered a 'java/io/FileInputStream' (0x2dfa8910) as finalizable
Registered a 'java/io/FileOutputStream' (0x2dfa89c8) as finalizable
Registered a 'java/io/FileOutputStream' (0x2dfa8a08) as finalizable
Registered a 'java/lang/ClassLoader$NativeLibrary' (0x2dfb4090) as finalizable
Registered a 'java/io/FileInputStream' (0x2dfb4db8) as finalizable
Registered a 'java/io/FileInputStream' (0x2dfc9e20) as finalizable
Registered a 'finalexc' (0x2dfcbfb8) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
return 0x2b2a3618
allocate_handle 33 0x5431f8
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/handles.cpp:34
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error
(/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34),
pid=17186, tid=1111291088
# assert(SharedSkipVerify || obj->is_oop()) failed: sanity check
#
# JRE version: 6.0
# Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode linux-mips )
# An error report file with more information is saved as:
# /home/yangyongqiang/benchmark/regression/hs_err_pid17186.log
@@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0
@@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
=========================================================
With Xint, output is:
=========================================================
Registered a 'finalexc' (0x2dfcbe88) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfb5c60) as finalizable
finalize 1
finalize 2
finalize 3
finalize 4
Registered a 'finalexc' (0x2dfb5c68) as finalizable
finalize 5
Registered a 'finalexc' (0x2dfb5c68) as finalizable
finalize 6
Registered a 'finalexc' (0x2dfb5c68) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
Registered a 'finalexc' (0x2dfa0000) as finalizable
finalize 7
finalize 8
=======================================================
On Fri, Dec 10, 2010 at 4:42 AM, Y. Srinivas Ramakrishna
<y.s.ramakrishna at oracle.com> wrote:
> 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
>>>>
>>>
>>
>>
>>
>
>
--
Best Wishes
Yongqiang Yang
More information about the hotspot-dev
mailing list