RFR: 8210498: nmethod entry barriers

[Andrew Haley]

On 1/7/20 10:25 AM, Per Liden wrote:
> 
> On 1/7/20 11:04 AM, Andrew Haley wrote:
>> On 1/7/20 9:22 AM, erik.osterlund at oracle.com wrote:
> [...]
>>> In the alternative solution that biases the cost towards arming, instead
>>> of calling, you would
>>> instead walk the code cache and explicitly arm nmethods by patching in a
>>> jump over nops in the
>>> verified entry (for all nmethods).
>>>
>>> Disarming would be done by patching back nops over the jump on
>>> individual nmethods as they
>>> become safe to disarm.
>>
>> Aha! That'd be a much simpler method for AArch64, for sure. We already have
>> a nop at the start of every method, so we could rewrite it as a simple
>> jump.
> 
> But as Erik hinted, the main problem with this alternative is that 
> arming becomes an O(n) stop-the-world operation

O(n) I understand, but why stop the world?

> (where n is the number 
> of nmethods) rather than O(1), which is highly undesirable for ZGC.

Yeah, I get that. It's a choice between the devil and the deep blue sea.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671