Hi Richard, This looks good to me. One question though.
Suppose some methods got compiled/optimized with the escape analysis. Then nothing prevents to enable the JVMTI capabilities later and use the JVMTI functions GetOwnedMonitorInfo()and GetOwnedMonitorStackDepthInfo(). Should enabling the capabilities cause deoptimization of the already optimized compiled frames? Is this considered to be a part of the JDK-8227745? Thanks, Serguei On 9/6/19 7:24 AM, Reingruber, Richard wrote:
Hi, could I please get reviews for Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8230677/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8230677 The JVMTI functions GetOwnedMonitorInfo() and GetOwnedMonitorStackDepthInfo() can be used to retrieve objects locked by a thread. In terms of escape analysis those references escape and optimizations like scalar replacement become invalid. The runtime currently cannot cope with objects escaping through JVMTI (try included tests). Therefore escape analysis should be disabled if an agent requests the capabilities can_get_owned_monitor_info or can_get_owned_monitor_stack_depth_info. This was taken out of JDK-8227745 [1] to make it smaller. With JDK-8227745 there's no need to disable escape analysis, instead optimizations based on escape analysis will be reverted just before objects escape through JVMTI. I've run tier1 tests. Thanks, Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8227745
