RFR(XXS): 8186667: InterpreterCodeSize overflows on AIX
doug.simon at oracle.com
Wed Aug 23 17:40:25 UTC 2017
We ran into similar problems while developing JVMCI and I suggested that InterpreterCodeSize should be computed:
Unfortunately, the runtime team closed it with "will not fix".
> On 23 Aug 2017, at 18:30, Volker Simonis <volker.simonis at gmail.com> wrote:
> Hi Goetz,
> thanks for the review. Just pushed the change to jdk10/hs.
> I'm also forwarding this mail with your review to the corresponding
> mailing lists as I've just noticed that you've only sent it to me.
> On Wed, Aug 23, 2017 at 5:47 PM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
>> Hi Volker,
>> The change looks good, thanks.
>> Best regards, Götz
>>> Am 23.08.2017 um 17:33 schrieb Volker Simonis <volker.simonis at gmail.com>:
>>> can somebody please review this tiny fix which only affects the ppc64 platforms:
>>> The fix for JDK-8172020 increased some interpreter entry points
>>> (notably the return entry points) considerably because it added
>>> special handling for popframe/earlyreturn in cases where debugging is
>>> This was just enough to overflow the current InterpreterCodeSize on
>>> AIX/ppc64 which was 230K until now:
>>> # Internal Error (interpreter.hpp:105), pid=16449790, tid=258
>>> # guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed:
>>> not enough space for interpreter generation
>>> Apparently we've only done debugging tests on jdk10 (and not jdk10-hs)
>>> so we've only noticed this now after jdk10-hs was integrated into
>>> As solution I propose to set InterpreterCodeSize to 256K on ppc64 to
>>> be on the safe side again.
>>> Thank you and best regards,
More information about the hotspot-dev