RFR 8166972: [JVMCI] reduce size of interpreter when JVMCI is enabled

[Vladimir Kozlov]

On 10/10/16 1:39 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/8166972/webrev
> https://bugs.openjdk.java.net/browse/JDK-8166972
>
> While investigating the size of the generated interpreter with -XX:+UseJVMCICompiler we noticed that the deopt entry points had gotten significantly larger.  JVMCI adds a relatively small amount of code to that entry point but it turns out there are 100 copies of this code being emitted, the 10 TOS types times 10 step values.  The extra code is only needed for the execution of the first bci, which is vtos with a 0 step.  The extra space had put us on the edge of the space limit for the interpreter.
>
> Tested with Graal and also a JPRT test submission where this assembler logic was on by default in builds that define INCLUDE_JVMCI.  Basically I replaced the UseJVMCICompiler tests in this webrev with true.

Looks good.

>
> As an aside, there are way too many deopt entry points.  In a stock JDK, the interpreter takes up 137K, of which 30K are the deopt entry points.  This is from -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter  -version for 8u92.  All the sub word types are smeared into itos but are generated separately, so there are really only 6 types instead of 10.  And I think step values above 5 are unnecessary too since that’s the longest fixed length encoding and the deopt machinery doesn’t appear to be prepared to handle a variable length byte code step value.  It probably doesn’t matter in the end but I was very surprised by this.
>

You can file RFE for Runtime group to look in next reelase. On other hand it is KBytes only.

Thanks,
Vladimir