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

[Christian Thalinger]

On Tue, 2010-04-20 at 15:39 -0700, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6943485
> 
> 6943485: JVMTI always on capabilities change code generation too much
> Reviewed-by:
> 
> 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.

The changes look good and I think the changes are OK.

-- Christian