RFR: 8358696: Assert with extreme values for -XX:BciProfileWidth

[Marc Chevalier]

On Fri, 4 Jul 2025 21:47:24 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

> **Issue**
> Extreme values for BciProfileWidth flag such as `java -XX:BciProfileWidth=-1 -version` and `java -XX:BciProfileWidth=100000 -version `results in assert failure `assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `. This is observed in a x86 machine.
> 
> **Analysis** 
>  On debugging the issue, I found that increasing the size of the interpreter using the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` prevented the above mentioned assert from failing for large values of BciProfileWidth.  
> 
> **Proposal** 
> Considering the fact that larger BciProfileWidth results in slower profiling, I have proposed a range between 0 to 5000 to restrict the value for BciProfileWidth for x86 machines. This maximum value is based on modifying the `InterpreterCodeSize` variable in `src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp` using the smallest `InterpreterCodeSize` for all the architectures.  As for the lower bound, a value of -1 would be the same as 0, as this simply means  no  return bci's will be recorded in ret profile. 
> 
> **Issue in AArch64**
> Additionally running the command `java -XX:BciProfileWidth= 10000 -version` (or larger values) results in a different failure  `assert(offset_ok_for_immed(offset(), size)) failed: must be, was: 32768, 3` on an AArch64 machine.This is an issue of maximum offset for `ldr/str` in AArch64 which can be fixed using `form_address`  as mentioned in [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736). In my preliminary fix using `form_address` on AArch64 machine. I had to modify 3 `ldr` and 1 `str` instruction (in file `src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp` at line number 926, 983, and 997). With this fix  using `form_address`, `BciProfileWidth` works for maximum of 5000 after which it crashes with`assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000772b63a7a3a0 <= 0x0000772b63b75159 <= 0x0000772b63b75158 `.  Without this fix `BciProfileWidth` works for a maximum value of 1300.   Currently, I have suggested to restrict the upper bound on AArch64 to 1000 instead 
 of fixing it with `form_address`. 
> 
> **Question to reviewers**
> Do you think this is a reasonable fix ?  For AArch64 do you suggest fixing using `form_address` ? If yes, do I fix it under this PR or create another one ?

One nit, one open comment.

Not of a lot of opinion on whether to use `form_address` instead.  Since `BciProfileWidth` is a develop flag, I'm not too annoyed if we limit it to avoid some change that would affect product builds. Except of course if the offset issue is a deeper problem that deserves to be solved anyway.

src/hotspot/share/runtime/globals.hpp line 1354:

> 1352:           range(0, 8)                                                       \
> 1353:                                                                             \
> 1354:   develop(intx, BciProfileWidth, 2,                                         \

Recently, I've seen someone complaining about useless use of `intx`, saying that is brings less readability than a more fixed-width type when not needed. Here, [0, 5000] fits in 16 bits (even signed). One could change that into a simple `int` or something like that.

src/hotspot/share/runtime/globals.hpp line 1357:

> 1355:           "Number of return bci's to record in ret profile")                \
> 1356:           range(0, AARCH64_ONLY(1000) NOT_AARCH64(5000))                    \
> 1357:                                                                             \

Maybe that's one empty line too much (cf. other spacing just around).

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

PR Review: https://git.openjdk.org/jdk/pull/26139#pullrequestreview-3041683534
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2221609770
PR Review Comment: https://git.openjdk.org/jdk/pull/26139#discussion_r2221600897