RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken

[serguei.spitsyn at oracle.com]

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