RFR: 8278793: Interpreter(x64) intrinsify Thread.currentThread() [v2]

[David Holmes]

On Fri, 17 Dec 2021 12:02:49 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this enhancement.
>> This makes Thread.currentThread() eight times faster on my box when running in interpreter.
>> 
>> Passes t1-t4
>> 
>> As suggested I added a related fix to Shenandoah.
>> Shenandoah LB was using InterpreterMacroAssembler version of call_VM_leaf_base (it's virtual).
>> The interpreter version adds a check on last_sp, since the intrinsic is not setting up a new frame, this check is faulty.
>> Other GC seems to always use the base version, so let's use the base version in Shenandoah also.
>> No issues found when locally running gc/shenandoah.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use resolve_oop_handle instead

Ditto what Dan said :)

Historically we haven't worried about currentThread() interpreter performance because the method is so hot during VM init that it should be quickly compiled anyway. Perhaps that has changed over time and we didn't notice. It would be interesting to see if there is any observable startup benefit here.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6833