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

[serguei.spitsyn at oracle.com]

Hi Richard,

Thank you for the reply.
It is correct, the can_get_owned_monitor_info and 
can_get_owned_monitor_stack_depth_info are onload capabilities.
And I do not see yet how is the capability can_tag_objects used in the 
escape analysis.

Thanks,
Serguei

On 9/9/19 02:43, Reingruber, Richard wrote:
> Hi Serguei, Dean,
>
>    > This looks good to me.
>
> Thanks for reviewing the change, Serguei.
>
>    > 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?
>
> Dean is right can_get_owned_monitor_info and can_get_owned_monitor_stack_depth_info are onload capabilities:
>
> see JvmtiManageCapabilities::init_onload_capabilities()
> http://hg.openjdk.java.net/jdk/jdk/file/8009a9c36251/src/hotspot/share/prims/jvmtiManageCapabilities.cpp#l127
>
> So they cannot be enabled later.
>
> Good question anyway, because can_tag_objects is an always capability and has the same issues with
> escape analysis.
>
>    > Is this considered to be a part of the JDK-8227745?
>
> Yes, but with JDK-8227745 there's no need to disable escape analysis.
>
> Thanks, Richard.
>
> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net> On Behalf Of dean.long at oracle.com
> Sent: Samstag, 7. September 2019 10:20
> To: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
>
> I had the same concern, and I think it's OK if these capabilities can
> only be enabled during OnLoad.
>
> dl
>
> On 9/6/19 6:08 PM, serguei.spitsyn at oracle.com wrote:
>> 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