review (S) for 6943485: JVMTI always on capabilities change code generation too much

Tom Rodriguez tom.rodriguez at
Tue Apr 20 15:39:54 PDT 2010

6943485: JVMTI always on capabilities change code generation too much

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.

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.

More information about the hotspot-compiler-dev mailing list