RFR(m): 8221734: Deoptimize with handshakes
robbin.ehn at oracle.com
Mon May 20 08:37:53 UTC 2019
> I'm not concerned about combining these.
> One nit in the test:
> 59 Thread.currentThread().sleep(10);
> should just be Thread.sleep(10) as its not an instance method.
Fixed in v4 which contains the simplifications in biased locking requested by
Sending v4 to RFR mail.
>> Good news, no issues found with deopt with handshakes.
>> This is v3:
>> This full inc from v2 (review + stress test):
>> This inc is the review part from v2:
>> This inc is the additional stress test with bug fixes:
>> Additional biased locking change:
>> The original code use same copy of markOop in revoke_and_rebias.
>> The keep same behavior I now pass in that copy into fast_revoke.
>> The stress test passes hundreds of iterations in mach5.
>> Thousands stress tests locally, the issues above was reproduce-able.
>> Inc changes also passes t1-5.
>> As usual with this change-set, I'm continuously running more test.
>> Thanks, Robbin
>> On 2019-04-25 14:05, Robbin Ehn wrote:
>>> Hi all, please review.
>>> Let's deopt with handshakes.
>>> Removed VM op Deoptimize, instead we handshake.
>>> Locks needs to be inflate since we are not in a safepoint.
>>> Goes on top of:
>>> Passes t1-7 and multiple t1-5 runs.
>>> A few startup benchmark see a small speedup.
>>> Thanks, Robbin
More information about the hotspot-compiler-dev