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
