RFR: 8298720: Insufficient error handling when CodeBuffer is exhausted

[Tobias Hartmann]

On Thu, 5 Jan 2023 08:01:42 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi! Thanks for handling RISC-V at the same time. I can help arrange some necessary tests on linux-riscv64 for those changes.
>
>> Thanks @RealFYang! It's mostly about verifying that I did not miss any label in the `reset_labels` calls. You should be able to hardcode the bailout to always true and check if we don't hit any assert.
> 
> Hi, fastdebug bootcycle is fine on linux-riscv64 platform.
> And If I hardcoded the bailout to always true, I got following assertion error when I do native fastdebug build on both aarch64 and riscv64 platforms:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/realfyang/openjdk-jdk/src/hotspot/share/opto/output.cpp:3241), pid=2565744, tid=2566009
> #  assert(!C->failing()) failed: Must not have pending failure. Reason is: CodeCache is full
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-adhoc.realfyang.openjdk-jdk)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-adhoc.realfyang.openjdk-jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # V  [libjvm.so+0x14fa71c]  PhaseOutput::scratch_emit_size(Node const*)+0x314

Thanks for testing, @RealFYang. That assert is expected as the code assumes that the scratch buffer is always large enough in size and code emission should never fail. Of course, that's not true when hardcoding the bailout.

Missing to reset a label before the bailout would lead to a `"Label was never bound to a location, but it was used as a jmp target"` assert. Thanks for verifying that this is not the case.

-------------

PR: https://git.openjdk.org/jdk/pull/11839