[aarch64-port-dev ] RFR: 8144498: aarch64: large code cache generates SEGV

[Edward Nevill]

Hi,

Please review the following webrev

http://cr.openjdk.java.net/~enevill/8144498/webrev.0/

JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8144498

This fixes an issue when random SEGVs were generated with -XX:ReservedCodeCacheSize > 128m

The problem was that pd_call_destination was using addr() rather than orig_addr. IE. It was using the address in the copied, but not relocated code.

It was then following a call destination to determine whether or not this was a call to a trampoline (in order that it could substitute the final trampoline address).

Usually this worked OK because it ended up just referencing a random address in the code buffer. However, very occasionally it would point to a trampoline somewhere in the code buffer and get a false positive.

In this case it would substitute the final address of that trampoline.

The result was that it would very occasionally relocate the address of some call to a random trampoline stub.

I have tested this with jtreg hotspot and langtools with -XX:ReservedCodeCacheSize=256m and without specifying any ReservedCodeCacheSize (so it defaults to 128m).

With ReservedCodeCacheSize == default

Hotspot (original): Test results: passed: 935; failed: 22; error: 12
Hotspot (patched): Test results: passed: 942; failed: 15; error: 12
Langtools (original): Test results: passed: 3,313; failed: 33
Langtools (patched): Test results: passed: 3,316; failed: 33

With -XX:+ReservedCodeCacheSize=256m

Hotspot (original): Test results: passed: 865; failed: 19; error: 85
Hotspot (patched): Test results: passed: 946; failed: 10; error: 13
Langtools (original): Test results: passed: 3,049; failed: 77; error: 223
Langtools (patched): Test results: passed: 3,314; failed: 33

So in all cases it generates results as good, or better than the original. In the case of langtools with a 256m buffer it goes from 300 failures+errors to just 33.

I have also tested this with EEMBC GrinderBench which also showed the problem every few 100 runs. I have run this over 5000 times with no occurrence of the problem.

Thanks for your review,
Ed.