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