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

[David Holmes]

Hi Richard,

On 7/09/2019 12: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.

What bothers me about this is that it seems like escape analysis is 
doing something wrong in this case. If the object is thread-local but is 
being synchronized upon then either:
a) the synchronization is elided and so the object will not appear in 
the set of owned monitors; or
b) the fact synchronization occurs renders the object ineligible to be 
considered thread-local, and so there is no problem with it appearing in 
the set of owned monitors

I think there is a bigger design philosophy issue here about the 
interaction of escape analysis and debugging/management frameworks in 
general. I'd like to see a very clear description on exactly how they 
should interact.

Cheers,
David

> 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
>