Unexpected behaviour of NativeJump::patch_verified_entry on some CPUs

[Alexander Miloslavskiy]

Hello,

TLDR: Please run test application in [3], 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 [1].
The bug is already reported as JDK-8213961 [2].

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 [3].

I believe it's known as Intel CPU problem AI33, see [4]. 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:
1)
     Expected = E9BBFFFFFF
     Actual   = EBFEEBFEFF
2)
     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 [3]
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 
slow.

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-November/031364.html
[2] https://bugs.openjdk.java.net/browse/JDK-8213961
[3] https://github.com/homo-programmatis/OpenJDK_PatchRunningCode/releases
[4] http://download.intel.com/design/processor/specupdt/313279.pdf