[aarch64-port-dev ] RFR: 8146286: aarch64: guarantee failures with large code cache sizes on jtreg test java/lang/invoke/LFCaching10/LFMultiThreadCachingTest.java

[Edward Nevill]

Hi,

The following webrev

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

JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8146286

The problem is that during code buffer expansion the code buffer can be moved so that a BL is no longer in range. Normally this would resolve to the targets trampoline.

However this is inhibited during code buffer expansion because of the following in get_trampoline_for()

address trampoline_stub_Relocation::get_trampoline_for(address call, nmethod* code) {
  // There are no relocations available when the code gets relocated
  // because of CodeBuffer expansion.
  if (code->relocation_size() == 0)
    return NULL;

The problem is that the relocs have not been created yet, so get_trampoline_for cannot resolve to the trampoline.

The solution I have adopted is to always generate a BL to self in MacroAssembler::trampoline_call.

In Relocation::pd_call_destination when it detects a call to self it does not attempt to do the relocation but just leaves it as a call to self (there is no point in trying to relocate the call to self to point to the original destination since that is in the old copy of the code buffer and could be out of range).

During final relocation the call to self is then relocated to the correct value.

Repeated testing with the above test shows that the problem has been resolved.

I have also tested with jtreg hotspot/langtools and jdk, before and after patching and with and without -XX:+ReservedCodeCacheSize=256m with no additional failures.

OK to push?
Ed.