JDK-6943485 : JVMTI always on capabilities change code generation too much
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2010-04-13
  • Updated: 2011-01-19
  • Resolved: 2010-05-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs18Fixed
Related Reports
Relates :  
JDK-7050591 - capabilities in init_onload_capabilities() need to be revisited
Relates :  
JDK-6885609 - java -client -XX:-JavaMonitorsInStackTrace cause
Description
The set of always on capabilities include thing which will cause changes in the code the compiler generates which interferes with using JVMTI to support profiling since you aren't profiling the code you would really be executing.  In particular this piece of code should change.

  JvmtiExport::set_can_access_local_variables(
    avail.can_access_local_variables  ||
    avail.can_redefine_classes ||
    avail.can_retransform_classes);
Comments
EVALUATION The set of always on JVMTI capabilities include thing which will cause changes in the code the compiler generates which interferes with using JVMTI to support profiling since you aren't profiling the same generated code that you would be executing. In particular the redefine and transform classes capabilities set the JvmtiExport::can_access_local_variables() flag which causes the compilers to keep all Java locals live even if they aren't needed for computation. Additionally we will currently turn of EA is this is set, which was done as the fix for 6895383. I've changed the setting of JvmtiExport::can_access_local_variables to only be driven by the two capabilities can_access_locals_variables and can_generate_breakpoints which should restrict these to be set when running under a debugger, since the original intent of keeping Java locals alive was to help simulate debugging while running under the interpreter where Java locals keep their values until they are overwritten. JvmtiExport::can_access_local_variables is only used by the compilers so this doesn't affect any other part of the system. I also moved some code which kept locals live in exception paths under the can_access_live_locals flag which made the flag can_examine_or_deopt_anywhere go dead. There were also some variables Compilation::_needs_debug_information and Compile::_deopt_happens which are always true and always must be true that I just deleted. I also fixed a possibly missing dependency for class redefinition when used with EA. Tested with runthese and all the NSK serviceability tests. Also compared the code we generate when running with and without an agent to make sure they were the same.
30-04-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b4776199210f
27-04-2010