-
Enhancement
-
Resolution: Unresolved
-
P4
-
9, 10
Make CodeBuffer dynamically grow/shrink as needed without having to provide a guess of how much space we need in advance
ForJDK-8079156 we had to manually change the instr buffer size for CodeBuffer to account for StackShadowPages=50 (it only had enough room for StackShadowPages=32).
It seems fragile to have to provide a guess on how big the CodeBuffer needs to be, then hope that the testing will catch all the cases where we might turn on/off some features that might have an impact on CodeBuffer instr sizes.
A robust solution would be to make CodeBuffer figure out on its own how large buffers it needs (allocating more or compacting as needed).
One additional benefit would be less space requirements (assuming we can compact the buffer space) compared to current solution, where we allocate high and hope we have enough room, but most certainly waisting some in the process.
For
It seems fragile to have to provide a guess on how big the CodeBuffer needs to be, then hope that the testing will catch all the cases where we might turn on/off some features that might have an impact on CodeBuffer instr sizes.
A robust solution would be to make CodeBuffer figure out on its own how large buffers it needs (allocating more or compacting as needed).
One additional benefit would be less space requirements (assuming we can compact the buffer space) compared to current solution, where we allocate high and hope we have enough room, but most certainly waisting some in the process.
- relates to
-
JDK-8080157 assert(allocates2(pc)) failed: not in CodeBuffer memory
- Closed
-
JDK-8219712 code_size2 (defined in stub_routines_x86.hpp) is too small on new Skylake CPUs
- Resolved
-
JDK-8079156 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50
- Closed