JDK-8248411 : AArch64: Insufficient error handling when CodeBuffer is exhausted
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,15,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2020-06-26
  • Updated: 2024-02-07
  • Resolved: 2020-10-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15 JDK 16
11.0.12-oracleFixed 15.0.2Fixed 16 b22Fixed
Related Reports
Relates :  
JDK-8298720 - Insufficient error handling when CodeBuffer is exhausted
Relates :  
JDK-8325326 - compiler/codecache/TestStressCodeBuffers.java assertion on AIX
Description
Test compiler/profiling/spectrapredefineclass/Launcher.java failed with 'relocation addr must be in this section'

The full error message:

#  Internal Error (.../open/src/hotspot/share/asm/codeBuffer.hpp:198)
#  assert(allocates2(pc)) failed: relocation addr must be in this section

This seems to be unstable - out of 10 rerun attempts, only 1 have failed.

The full stack trace:

Stack: [0x0000fffbcfc00000,0x0000fffbcfe00000],  sp=0x0000fffbcfdfac50,  free space=2027k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x7ae498]  CodeSection::relocate(unsigned char*, RelocationHolder const&, int) [clone .part.0]+0x1d0
V  [libjvm.so+0x80faa0]  CompiledStaticCall::emit_to_interp_stub(CodeBuffer&, unsigned char*)+0x90
V  [libjvm.so+0x302b98]  CallStaticJavaDirectNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x150
V  [libjvm.so+0x1149260]  PhaseOutput::fill_buffer(CodeBuffer*, unsigned int*)+0xad0
V  [libjvm.so+0x7ed6ac]  Compile::Code_Gen()+0x39c
V  [libjvm.so+0x7f35b0]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xff0
V  [libjvm.so+0x642dec]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xfc
V  [libjvm.so+0x8027a8]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcd0
V  [libjvm.so+0x803b40]  CompileBroker::compiler_thread_loop()+0x638
V  [libjvm.so+0x13cf138]  JavaThread::thread_main_inner()+0x1f8
V  [libjvm.so+0x13d6b00]  Thread::call_run()+0xf8
V  [libjvm.so+0x1122d90]  thread_native_entry(Thread*)+0x120
C  [libpthread.so.0+0x7d40]  start_thread+0xb4
Comments
Hi Tobias, regarding JDK-8325326 we saw it now 4 times in the central runs of jtreg HS tier1 since yesterday, so it can be reproduced in our central HS jtreg :tier1 runs. When running only the single test compiler/codecache/TestStressCodeBuffers.java standalone, I have to set -vmoption:-Xmx768m 8and of course use fastdebug binaries) to get the assertion.
07-02-2024
Sounds good. No, I'm not aware of any recent change that would explain this but it might well be a core libraries change or something that triggers this.
07-02-2024
Hi Tobias, I created 8325326 compiler/codecache/TestStressCodeBuffers.java assertion on AIX ; we saw this assert two times since yesterday, all of a sudden ! Is there some suspicious change that came in yesterday ?
06-02-2024
Yes, that sounds like a missing bailout.
06-02-2024
we still we a similar failure on AIX today (ppc64) : # Internal Error (/workspace/openjdk-jdk-aix_ppc64-dbg/jdk/src/hotspot/share/asm/codeBuffer.hpp:212), pid=3342872, tid=3599 # assert(allocates2(pc)) failed: relocation addr must be in this section Could this be related to 'insufficient' error handling ? The error shows up in the test compiler/codecache/TestStressCodeBuffers .
06-02-2024
Fix Request(11u) Backporting this improves runtime stability and fixes intermittent test failures in hotspot tier1. 15u Patch doesn't apply cleanly. Minor adjustments in output.cpp, which only includes formatting changes. Risk is low, since most changes are add additional null checks and make the code more defensive. Review: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-March/005203.html Webrev: https://cr.openjdk.java.net/~cgo/8248411/backport-11u.00/
05-03-2021
Fix Request 15u: Not clean, using C++11 template vararg (replaced by macros). Improved stability. Public review. https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/046030.html
20-11-2020
http://cr.openjdk.java.net/~phedlin/tr8248411.15u/webrev/index.html
17-11-2020
Changeset: f279ddfa Author: Patric Hedlin <phedlin@openjdk.org> Date: 2020-10-22 15:56:56 +0000 URL: https://git.openjdk.java.net/jdk/commit/f279ddfa
22-10-2020