[aarch64-port-dev ] unimplemented code patching in AARCH64
Jie He (Arm Technology China)
Jie.He at arm.com
Tue Oct 29 09:33:29 UTC 2019
Hi
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. 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.
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.
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.
[1]. http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-August/007876.html
B.R
Jie He
More information about the aarch64-port-dev
mailing list