RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

[Reingruber, Richard]

Hi,

> The mach5 test run is good.

Thanks Serguei and thanks to everybody providing feedback! I just pushed the change.

Just curious: is mach5 an alias for tier5? And is this mach5 the same as in "Job:
mach5-one-rrich-JDK-8238585-2-20200604-1334-11519059" which is the (successful) submit repo job?

Thanks,
Richard.

-----Original Message-----
From: serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com> 
Sent: Donnerstag, 4. Juni 2020 04:07
To: Reingruber, Richard <richard.reingruber at sap.com>; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

Hi Richard,

The mach5 test run is good.

Thanks,
Serguei


On 6/2/20 10:57, Reingruber, Richard wrote:
> Hi Serguei,
>
>> This looks good to me.
> Thanks!
>
>  From an earlier mail:
>
>> I'm thinking it would be more safe to run full tier5.
> I guess we're done with reviewing. Would be good if you could run full tier5 now. After that I would
> like to push.
>
> Thanks, Richard.
>
> -----Original Message-----
> From: serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com>
> Sent: Dienstag, 2. Juni 2020 18:55
> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; Reingruber, Richard <richard.reingruber at sap.com>; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
>
> Hi Richard,
>
> This looks good to me.
>
> Thanks,
> Serguei
>
>
> On 5/28/20 09:02, Vladimir Kozlov wrote:
>> Vladimir Ivanov is on break currently.
>> It looks good to me.
>>
>> Thanks,
>> Vladimir K
>>
>> On 5/26/20 7:31 AM, Reingruber, Richard wrote:
>>> Hi Vladimir,
>>>
>>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
>>>> Not an expert in JVMTI code base, so can't comment on the actual
>>>> changes.
>>>>    From JIT-compilers perspective it looks good.
>>> I put out webrev.1 a while ago [1]:
>>>
>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/
>>> Webrev(delta):
>>> http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/
>>>
>>> You originally suggested to use a handshake to switch a thread into
>>> interpreter mode [2]. I'm using
>>> a direct handshake now, because I think it is the best fit.
>>>
>>> May I ask if webrev.1 still looks good to you from JIT-compilers
>>> perspective?
>>>
>>> Can I list you as (partial) Reviewer?
>>>
>>> Thanks, Richard.
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245.html
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030340.html
>>>
>>> -----Original Message-----
>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>> Sent: Freitag, 7. Februar 2020 09:19
>>> To: Reingruber, Richard <richard.reingruber at sap.com>;
>>> serviceability-dev at openjdk.java.net;
>>> hotspot-compiler-dev at openjdk.java.net
>>> Subject: Re: RFR(S) 8238585: Use handshake for
>>> JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make
>>> compiled methods on stack not_entrant
>>>
>>>
>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
>>> Not an expert in JVMTI code base, so can't comment on the actual
>>> changes.
>>>
>>>    From JIT-compilers perspective it looks good.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585
>>>>
>>>> The change avoids making all compiled methods on stack not_entrant
>>>> when switching a java thread to
>>>> interpreter only execution for jvmti purposes. It is sufficient to
>>>> deoptimize the compiled frames on stack.
>>>>
>>>> Additionally a handshake is used instead of a vm operation to walk
>>>> the stack and do the deoptimizations.
>>>>
>>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and
>>>> release builds on all platforms.
>>>>
>>>> Thanks, Richard.
>>>>
>>>> See also my question if anyone knows a reason for making the
>>>> compiled methods not_entrant:
>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html
>>>>
>>>>