[master] RFR: Implement non-racy fast-locking [v2]

[Roman Kennke]

On Wed, 27 Jul 2022 07:22:10 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Arm fix by shade
>
> src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp line 80:
> 
>> 78: 
>> 79:   movptr(disp_hdr, Address(obj, hdr_offset));
>> 80:   andb(disp_hdr, ~0x3); // Clear lowest two bits. 8-bit AND preserves upper bits.
> 
> I see you added a new andb instruction so that you can clear two low order bits while preserving the others. It's worth noting that the immediates are sign extended. So I don't think you need to do that. For example you could do and with -4 of any signed immediate size to clear the low order 2 bits only.

Right. The downside is that the instruction encoding is larger (32 vs 16 bits, I believe). I don't think it matters much, though. I'll do what you suggest.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9459:
> 
>> 9457:   movptr(locked_hdr, hdr);
>> 9458:   // Clear lowest two bits: we have 01 (see above), now flip the lowest to get 00.
>> 9459:   xorptr(locked_hdr, markWord::unlocked_value);
> 
> So you want to compute 1) the header but with low order bits are zero, and 2) the header but low order bits are 01.
> I think I would compute the first one by using bitwise and with -4. Then I would compute the second by taking the first value + 1. The benefit is that you don't have to rely on the low order bits being either 00 or 01 in the header then, making it more future proof. Somebody might want to use 10 for something, for example.

10 is already used for monitors. Flipping the lowest bit would make it 11 - a value that should be impossible in this scenario, and which would make the CAS fail. However, what you suggest is clearer and doesn't rely on implicit knowledge, I'll do that, instead. Thank you!

-------------

PR: https://git.openjdk.org/lilliput/pull/51