RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline"

Aleksey Shipilev shade at openjdk.java.net
Mon May 16 16:04:48 UTC 2022


On Mon, 16 May 2022 15:33:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This problem is, I believe, caused by an assertion left in the source code after development.
> The fix is simply to remove the assertion.
> 
> It's not at all easy to reproduce this bug, being a very intermittent failure, but in the end I reproduced it by making `-XX:+StressCodeBuffers` much more stressful, like so:
> 
> 
> diff --git a/src/hotspot/share/asm/codeBuffer.cpp b/src/hotspot/share/asm/codeBuffer.cpp
> index ddd946d7542..c74ba21cf63 100644
> --- a/src/hotspot/share/asm/codeBuffer.cpp
> +++ b/src/hotspot/share/asm/codeBuffer.cpp
> @@ -837,7 +837,8 @@ void CodeBuffer::expand(CodeSection* which_cs, csize_t amount) {
>    if (StressCodeBuffers && blob() != NULL) {
>      static int expand_count = 0;
>      if (expand_count >= 0)  expand_count += 1;
> -    if (expand_count > 100 && is_power_of_2(expand_count)) {
> +    if (expand_count > 100 && // is_power_of_2(expand_count)
> +        expand_count % 40 == 0) {
>        tty->print_cr("StressCodeBuffers: have expanded %d times", expand_count);
>        // simulate an occasional allocation failure:
>        free_blob();

Okay, so what is supposed to happen on failure? I see `aarch64.ad` has two rules that use `__ zero_words`.

`clearArray_reg_reg` does:


    address tpc = __ zero_words($base$$Register, $cnt$$Register);
    if (tpc == NULL) {
      ciEnv::current()->record_failure("CodeCache is full");
      return;
    }

...while `clearArray_imm_reg` calls through to `MacroAssembler::zero_words(Register base, uint64_t cnt)`, which still enters this method without checking the result? Maybe the predicate saves us here, IDK.

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

PR: https://git.openjdk.java.net/jdk/pull/8730


More information about the hotspot-dev mailing list