RFR: 8269476: Skip nmethod entry barrier if there is no oops in the jit code [v2]
Andrew Haley
aph at openjdk.java.net
Mon Jun 28 13:45:06 UTC 2021
On Mon, 28 Jun 2021 13:26:15 GMT, 王超 <github.com+25214855+casparcwang at openjdk.org> wrote:
>>> You may need an additional instruction, e.g. uses MSB of disarmed_value to indicate always disarmed and test the bit before `cmpl`.
>>>
>>> Also, you need a new method to set the bit during nmethod registration.
>>>
>>> nmethod entry barrier tests is_armed() early, so may benefit more.
>>
>> The barrier can be bypassed only when the nmethod does not any contain oop relocation, if it's bypassed, it should always be bypassed, there is no need to test the bit of disarmed_value.
>>
>> I think several `nop` instruction can be added before `cmpl`, and patched to direct jump if the barrier can be bypassed. And when the nmethod is changed to contain oops again, the direct jump should be patched to `nop` again.
>>
>> `x86_instruction_opcode disarmed_value_addr, some_magic_number_immediate; jcc label;` : If there exists some instructions like this, only need to change `some_magic_number_immediate` to make the following `jcc` instruction alway jump, this is the dream version of code sequences, but I do not figure out which instructions can be used to implement this functionality.
>
> maybe `subl ; jcc` can be used to implement a more compact version, but the `nop`<->`jump` can benefit more
> > You may need an additional instruction, e.g. uses MSB of disarmed_value to indicate always disarmed and test the bit before `cmpl`.
> > Also, you need a new method to set the bit during nmethod registration.
> > nmethod entry barrier tests is_armed() early, so may benefit more.
>
> The barrier can be bypassed only when the nmethod does not any contain oop relocation, if it's bypassed, it should always be bypassed, there is no need to test the bit of disarmed_value.
On AArch64 we have
__ ldrw(rscratch1, guard);
// Subsequent loads of oops must occur after load of guard value.
// BarrierSetNMethod::disarm sets guard with release semantics.
__ membar(__ LoadLoad);
__ ldrw(rscratch2, thread_disarmed_addr);
__ cmpw(rscratch1, rscratch2);
__ br(Assembler::EQ, skip);
This `membar` is evil, and it would be very nice to be rid of it. If we have a `nop` before the guard load, we can patch it to jump around the whole sequence, so that would be my preferred thing to do.
On AArch64 we don't care about C1 patching at all, we just don't do any. It would be better IMO if everyone gave up C1 patching, but that's a discussion for another day.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4610
More information about the hotspot-dev
mailing list