-
Bug
-
Resolution: Duplicate
-
P4
-
7u80, 8, 9
-
x86
-
os_x
FULL PRODUCT VERSION :
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
FULL OS VERSION :
Darwin XXXX 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64
A DESCRIPTION OF THE PROBLEM :
I am using a profiler that profiles my application by instrumenting every method call in the JVM using the standard java.lang.instrument.Instrumentation framework.
When I profile my application with the JVM in interpreted mode (-Xint) everything works exactly as expected and I obtain a complete profile.
However when I don't run in interpreted mode I end up with an incomplete profile on some code paths, it appears that the instrumentation for some methods is simply not being called. It looks to me that it is only the 'intrinsic' methods where this is happening, and only for some code paths. My theory is that this occurs when the hotspot compiler decides to compile the method. It overlooks the fact that the method has been instrumented and therefore the instrumentation is lost.
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Did not try
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Use the Instrumentation framework to add some new code to an instrinsic method. A simple test case would be to print a char to System.err every time the method is called.
2. Create an application that uses this intrinsic method in such a way that the hotspot compiler will choose to compile it.
3. When you run this program you will find your new code is initially called, but at some point in the middle of the run it stops being called.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: any code added to instrinsic methods via the Instrumentation framework is always called.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
I have found that running in interpreted mode bypasses the bug. I have also found that explicitly disabling an intrinsic method using the -XX:DisableIntrinsic option will bypass the bug for that one method.
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
FULL OS VERSION :
Darwin XXXX 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64
A DESCRIPTION OF THE PROBLEM :
I am using a profiler that profiles my application by instrumenting every method call in the JVM using the standard java.lang.instrument.Instrumentation framework.
When I profile my application with the JVM in interpreted mode (-Xint) everything works exactly as expected and I obtain a complete profile.
However when I don't run in interpreted mode I end up with an incomplete profile on some code paths, it appears that the instrumentation for some methods is simply not being called. It looks to me that it is only the 'intrinsic' methods where this is happening, and only for some code paths. My theory is that this occurs when the hotspot compiler decides to compile the method. It overlooks the fact that the method has been instrumented and therefore the instrumentation is lost.
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Did not try
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Use the Instrumentation framework to add some new code to an instrinsic method. A simple test case would be to print a char to System.err every time the method is called.
2. Create an application that uses this intrinsic method in such a way that the hotspot compiler will choose to compile it.
3. When you run this program you will find your new code is initially called, but at some point in the middle of the run it stops being called.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: any code added to instrinsic methods via the Instrumentation framework is always called.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
I have found that running in interpreted mode bypasses the bug. I have also found that explicitly disabling an intrinsic method using the -XX:DisableIntrinsic option will bypass the bug for that one method.
- duplicates
-
-
- Open
-
-
-
- Open
-