harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Popov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-2306) [drlvm][jvmti] VM crashes if j.l.Thread is instrumented by JVMTI profiler
Date Fri, 24 Nov 2006 15:36:03 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-2306?page=comments#action_12452479 ] 
            
Ivan Popov commented on HARMONY-2306:
-------------------------------------

According to JVMTI spec, function GetCurrentThreadCpuTime(env, nanos_ptr) does not need access
to instance of j.l.Thread class. It is equivalent to calling GetThreadCpuTime(env, NULL, nanos_ptr)
that neither requires j.l.Thread instance. Both functions can be invoked at any time during
live phase, so nothing prohibits calling them during execution of constructor of j.l.Thread
object. This works fine with RI and should work with DRLVM.

I think implementation of JVMTI functions GetCurrentThreadCpuTime() and GetThreadCpuTime()
should be aware of the fact that the corresponding j.l.Thread instance for the current thread
can be not fully constructed and use some workaround in this case.


> [drlvm][jvmti] VM crashes if j.l.Thread is instrumented by JVMTI profiler
> -------------------------------------------------------------------------
>
>                 Key: HARMONY-2306
>                 URL: http://issues.apache.org/jira/browse/HARMONY-2306
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM, App-Oriented Bug Reports
>         Environment: Windows/ia32, Linux/ia32
>            Reporter: Ivan Popov
>         Attachments: just_a_workaround.patch, ThreadEventsTest.zip
>
>
> After applying fix for HARMONY-2200 to DRLVM (r475994), it appeared work well with instrumented
HelloWorld class. But now it crashes if profiler instruments system class java/lang/Thread.

> With debug build of DRLVM assertion is thrown:
>   .../vm/thread/src/thread_ti_timing.c:63: jthread_get_thread_cpu_time: Assertion `java_thread'
failed
> Here is typical stack trace from the VC++ debugger:
> >	harmonyvm.dll!GetObjectClass(JNIEnv_External * env=0x010177e8, _jobject * obj=0x00000000)
 Line 1052 + 0x4	C++
>  	harmonyvm.dll!vm_jthread_get_tm_data(_jobject * thread=0x00000000)  Line 189	C++
>  	harmonyvm.dll!jthread_get_thread_cpu_time(_jobject * java_thread=0x00000000, __int64
* nanos_ptr=0x0013f428)  Line 67	C
>  	harmonyvm.dll!jvmtiGetCurrentThreadCpuTime(jvmtiEnv_struct * env=0x00000004, __int64
* nanos_ptr=0x0013f428)  Line 113 + 0xc	C++
>  	ThreadEvents.dll!01c1162a() 	
>  	ThreadEvents.dll!01c11039() 	
>  	interpreter.dll!invokeJNI(unsigned int * args=0x0013f460, int sz=4, void (void)* f=0x01c11000)
 Line 50	C++
>  	interpreter.dll!interpreterInvokeStaticNative(StackFrame & prevFrame={...}, StackFrame
& frame={...}, Method * method=0x01ec5420)  Line 354	C++
>  	interpreter.dll!interpreterInvokeStatic(StackFrame & prevFrame={...}, Method *
method=0x01ec5420)  Line 3334	C++
>  	interpreter.dll!Opcode_INVOKESTATIC(StackFrame & frame={...})  Line 2093 + 0x6
C++
>  	interpreter.dll!interpreter(StackFrame & frame={...})  Line 2880	C++
>  	interpreter.dll!interpreterInvokeStatic(StackFrame & prevFrame={...}, Method *
method=0x01ec55b8)  Line 3285	C++
>  	interpreter.dll!Opcode_INVOKESTATIC(StackFrame & frame={...})  Line 2093 + 0x6
C++
>  	interpreter.dll!interpreter(StackFrame & frame={...})  Line 2880	C++
>  	interpreter.dll!interpreter_execute_method(Method * method=0x01e6f430, jvalue * return_value=0x00000000,
jvalue * args=0x0013f9f8)  Line 3188	C++
>  	interpreter.dll!JIT_execute_method(void * jh=0x00000000, _jmethodID * m=0x01e6f430,
jvalue * return_value=0x00000000, jvalue * args=0x0013f9f8)  Line 162 + 0x14	C++
>  	em.dll!DrlEMImpl::executeMethod(_jmethodID * meth=0x01e6f430, jvalue * return_value=0x00000000,
jvalue * args=0x0013f9f8)  Line 489 + 0x14	C++
>  	em.dll!ExecuteMethod(_jmethodID * meth=0x01e6f430, jvalue * return_value=0x00000000,
jvalue * args=0x0013f9f8)  Line 44	C++
>  	harmonyvm.dll!vm_execute_java_method_array(_jmethodID * method=0x01e6f430, jvalue *
result=0x00000000, jvalue * args=0x0013f9f8)  Line 51 + 0x19	C++
>  	harmonyvm.dll!vm_create_jthread(_jobject * * thread_object=0x0013fa70, JNIEnv_External
* jni_env=0x01fe9360, _jobject * group=0x00000000, char * name=0x0013f3c8, unsigned char daemon=0)
 Line 556 + 0x1e	C++
>  	harmonyvm.dll!vm_attach_internal(JNIEnv_External * * p_jni_env=0x0013fa74, _jobject
* * java_thread=0x0013fa70, JavaVM_External * java_vm=0x00fc20a0, _jobject * group=0x00000000,
char * name=0x0069250c, unsigned char daemon=0)  Line 595 + 0x1c	C++
>  	harmonyvm.dll!DestroyJavaVM(JavaVM_External * vm=0x00fc20a0)  Line 1450 + 0x19	C++
>  	java.exe!00402527() 	
>  	java.exe!00402b82() 	
>  	java.exe!0040111a() 	
>  	hyprt.dll!11105ed8() 	
>  	java.exe!004011ae() 	
> To reproduce this problem run attached test with simple JVMTI agent that replaces java/lang/Thread
class with the instrumented version (found in classes-instr directory). Test archive also
includes javap-disassembled bytecodes of these classes to see the difference.
> In reference VMs (Sun and JRockit) instrumenting their system class java/lang/Thread
in the same way works well. 
> PLEASE NOTE, this test cannot be applied to Sun or JRockit JREs, because it requires
instrumented version of their internal implementation of java/lang/Thread. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message