RIP values like 0xffffffff94bf7f80 due to patched NMethod

[Alexander Miloslavskiy]

Vladimir, thanks for your time!

It took a couple days to receive permission from user to share his 
hs_err.log files. I have submitted bugreport as you suggested (ID 
9058132), but there was no way to attach those files there.

On the other hand, frankly, hs_err.log are quite useless in this 
specific case. Without a core dump there was no chance to get any of the 
key insights.

I understand that a few bugs were fixed recently, but I guess since it 
sill happens on JRE11 it's a different problem.

I also studied the code to try to find how 0x90 can get written on top 
of jmp, but didn't find anything definite.

Following your lead, I have checked if crashing NMethod is freed.
* Its 'HeapBlock::Header::_used' contains 1
* NMethod fields match what they should be for old NMethod, so I think 
that this block is not owned by someone else yet.
* There are no pointers to old (crashing) NMethod anywhere except 
discarded (with addresses < RSP) stack of crashing thread. This worries 
me a bit, but I guess I simply don't know how JVM works.

Since my last mail I debugged it a bit more and found one new fact: just 
after crashing method was compiled with new optimization settings, the 
calling method also was compiled, fully inlining called method and 
therefore eliminating the need for called Method's NMethod. My intuition 
says that should be related, because the coincidence is too obvious. 
However, called Method's 'Method._code' still contains reference to new 
NMethod - looks like JVM didn't realize it's not needed.

This last fact is supported by one core dump so far, I still need to 
check others. Other facts I listed in my previous mail are supported by 
multiple dumps (and all I have checked).

Unfortunately, the bug only reproduces for our customer.