RFR(XXS): 8186667: InterpreterCodeSize overflows on AIX

[Doug Simon]

We ran into similar problems while developing JVMCI and I suggested that InterpreterCodeSize should be computed:

https://bugs.openjdk.java.net/browse/JDK-8166317

Unfortunately, the runtime team closed it with "will not fix".

-Doug

> 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.
> 
> Regards,
> Volker
> 
> 
> 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>:
>>> 
>>> Hi,
>>> 
>>> can somebody please review this tiny fix which only affects the ppc64 platforms:
>>> 
>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8186667/
>>> https://bugs.openjdk.java.net/browse/JDK-8186667
>>> 
>>> 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
>>> enabled.
>>> 
>>> 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
>>> jdk10.
>>> 
>>> As solution I propose to set InterpreterCodeSize to 256K on ppc64 to
>>> be on the safe side again.
>>> 
>>> Thank you and best regards,
>>> Volker