[aarch64-port-dev ] unimplemented code patching in AARCH64

[Andrew Haley]

On 10/29/19 9:33 AM, Jie He (Arm Technology China) wrote:

> Recently, I noticed some deoptimization in AARCH64, but not in X86,
> and found that when OSR compiled code encounter unresolved filed or
> not-loaded yet class, it has to initial a deoptimization. but in
> X86, it will do a code patching instead. so I realized the different
> SMC rules (ARM ARM b2.2.5) between x86 and AARCH64. It makes hard to
> do the same thing like X86 did.

Yes, and I don't believe we should. Hot-patching live code is fraught
with problems, and if we can recompile we should.

> I also noticed Andrew Dinn reported
> the performance issue of case TestLongVect in AARCH64, which caused
> by too much deoptimization in aarch64, and the similar case
> TestByteVect doesn't happen because the function test() couldn't
> enter OSR due to its byte code size (> 8000).  Details pls refer to
> [1].
> 
> and I think there are at least 2 options to implement the code
> patching in aarch64.

> 1, replace the origin jump to patch stub with a new jump to the
> patched code, no code copy any more, it could conform with b2.2.5.

Possibly.

> 2, move the jump address and patching data into a data section, let
> compiled code to be address independent code, like fPIC did, at
> first time launch, jump address should point to patch stub, and
> patching data is 0, after oop resolving, patching data should become
> oop address/offset, and jump address should become to loading code
> address.

That seems like a rather extreme solution.

> At the same time, I implement a workaround by changes in
> patchingstub, patch_code, to fix the TestLongVect according to
> option 1, which only fixes the part of code patching issues exposed
> by this test case, but still further tests are necessary for
> correctness.
> 
> Finally, I'm not sure if it is worth doing, because in general OSR
> shouldn't impact the real workload. But fixing it could bring the
> unified behavior between aarch64 and other platforms.

My thinking goes like this: proving that patching is safe is
difficult. The AArch64 rules are strict but have not yet been
formalized, and I know that we're doing some thing that I believe are
safe in practice but may not fully accord with the rules.

I have measured that deoptimization and recompilation due to
situations that would cause patching on x86 is only about 10% of all
recompilation events. 90% is due to tiered compilation events, where
C1 code is recompiled to C2. By not patching C1-compiled code we're
making things simpler and safer. IMO, x86 could do the same and no-one
would ever notice.

> [1]. http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-August/007876.html

This one should be investigated some more. It looks like a bug.

-- 
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