RFR(XS): 8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation
zhaixiang at loongson.cn
Fri Sep 14 11:31:14 UTC 2018
I just quoted the old thread
I think we should increase it more for future otherwise you will have to
always catch up with interpreter changes.
Increase it to 256 * 1024 and 224 * 1024
On 10/16/13 12:22 PM, Albert Noll wrote:
> could I have a review for this patch?
> bug: https://bugs.openjdk.java.net/browse/JDK-8026708
> webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/
> Problem: Not enough room for interpreter. My last patch did not solve
> the problem for solaris-amd64.
> A local build (solaris-amd64) of the most recent
> hotspot-comp version requires a template interpreter
> size of 211K (obtained with -XX:+PrintInterpreter).
> There have been some modifications to the template
> interpreter in the last couple of weeks which might have
> triggered this error.
> Solution: Increase interpreter size by 8k (32-bit and 64-bit).
> Testing: Failing test case in solaris-amd64
----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
I found that `InterpreterCodeSize` had been changed from 200K to 208K
 , then changed from 208K to 256K  by Albert. But if built
with-debug-level=fastdebug/slowdebug, it will be multiplied by four:
NOT_PRODUCT(code_size *= 4;) // debug uses extra interpreter code space
Then it might trigger Native memory allocation (malloc) failed to
allocate xxx bytes for CodeCache: no room for Interpreter issue.
I don't want to always catch up with interpreter changes by guessing the
suitable number, not too small, not too big :) Please give me some
suggestion about the root cause, thanks a lot!
More information about the jdk8u-dev