Unexpected behaviour of NativeJump::patch_verified_entry on some CPUs
alexandr.miloslavskiy at gmail.com
Thu Dec 13 13:32:22 UTC 2018
TLDR: Please run test application in , especially test 1, and report
if it shows any errors for you. It's most interesting to test on older
CPUs. Our affected customer has 'Pentium Dual-Core E5200'. If you have
access to such CPU's, please test! It will only take a couple minutes.
This is continuation of previous research .
The bug is already reported as JDK-8213961 .
The problem is that for one of our customers JVM randomly crashes with
crazy RIP values such as 0xffffffff94bf7f80 after replacing one NMethod
with another (due to optimization changes).
After much debugging, I was able to identify the problem as CPU issue
related to how Java patches methods that are currently executing. I was
also able to reproduce the issue in standalone snippet, see .
I believe it's known as Intel CPU problem AI33, see . If one core
executes code and the other core overwrites it at the same time, it
causes all sorts of curious effects. In this specific case, memory
writes targeting same bytes seem to be shuffled in some strange way.
Examples from the test application:
Expected = E9BBFFFFFF
Actual = EBFEEBFEFF
Expected = E9BBFFFFFF
Actual = E9BBFFFF90
What really surprises me is: is it really true that current Java
randomly crashes on specific older CPU's, and no one still knows? The
patching code in question was implemented even before those CPU's were
released for sale.
That Pentium E5200 is not the newest CPU, of course, but it's also not
exotic or very old.
I really hope to get some testing results from you guys to get some
estimation on how many customers could be affected.
Here's how to test:
1) Get binaries at 
2) Run it, select test 1, wait at least 10000 iterations.
3) If there're any errors at all, your CPU is affected.
4) If you have other CPU's at hand, please also test there :)
5) If you have errors, or if you're curious, please also try test 2.
Also, a question: Is it possible to force Java to only install compiled
methods when they are not executed, for example at safepoints? So far
the only solution I have for our customer is to disable compilers
completely, but I'm hesitant to suggest it as it will probably be quite
More information about the hotspot-compiler-dev