United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6943485 JVMTI always on capabilities change code generation too much
JDK-6943485 : JVMTI always on capabilities change code generation too much

Details
Type:
Bug
Submit Date:
2010-04-13
Status:
Resolved
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2010-05-05
Component:
hotspot
OS:
solaris_9
Sub-Component:
compiler
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs18
Fixed Versions:
hs18 (b04)

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b4776199210f
                                     
2010-04-27
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.
                                     
2010-04-30



Hardware and Software, Engineered to Work Together