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

[serguei.spitsyn at oracle.com]

Hi Richard,

Okay, thanks!
Serguei


On 9/9/19 11:26 PM, Reingruber, Richard wrote:
> Hi Serguei,
>
>    > And I do not see yet how is the capability can_tag_objects used in the escape analysis.
>
> I'll come up with a separate bug and a test that demonstrates it.
>
> The test will actually be a variant of
>
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.0/raw_files/new/test/hotspot/jtreg/serviceability/jvmti/IterateHeap/IterateHeapWithEscapeAnalysisEnabled.java
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.0/raw_files/new/test/hotspot/jtreg/serviceability/jvmti/IterateHeap/libIterateHeapWithEscapeAnalysisEnabled.c
>
>  From my webrev for JDK-8227745.
>
> I want to change it such that it acquires can_tag_objects during the live phase.
>
> Cheers, Richard.
>
>
> -----Original Message-----
> From: serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com>
> Sent: Dienstag, 10. September 2019 01:41
> To: Reingruber, Richard <richard.reingruber at sap.com>; dean.long at oracle.com; 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
>
> 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