Smaller byte code for small constants

[Paul Govereau]

Hi Vitaly,

Thanks for the response. The only benefit here is a slightly smaller 
classfile. However, if there is a risk of impacting the optimizer, it 
hardly seems worth it.

On 09/12/2014 07:00 PM, Vitaly Davidovich wrote:
> Hi Paul,
>
> This would increase the bytecode size of methods containing these
> scenarios, right? If so, having several of these may push a method over
> jit inlining heuristic that uses bytecode size.  This issue has come up
> in other contexts as well (e.g. asserts causing same problem).  I'd say
> until the jit inliner is changed to use something smarter (e.g. CFG
> complexity post some basic reductions or something like that), this has
> potential for perf regressions.
>
> Presumably interpreter may not like this either, but I don't know.
>
> Out of curiosity what's the practical benefit of saving a constant pool
> slot? Less VM memory overhead?
>
> Sent from my phone
>
> On Sep 12, 2014 2:42 PM, "Paul Govereau" <paul.govereau at oracle.com
> <mailto:paul.govereau at oracle.com>> wrote:
>
>     Currently, for long, float and double, javac will emit an ldc
>     instruction for small constants (aside from 0, 1, 2). For instance,
>     this statement:
>
>        long x = 3;
>
>     produces the code:
>
>        ldc2_w #index
>        lstore_n
>
>     However, we could save ourselves a constant pool slot with:
>
>        bipush 3
>        i2l
>        istore_n
>
>     The same trick can be used for float and double constants that
>     happen to be round integers (modulo the semantics of i2f?).
>
>     Are there bad consequences for the interpreter or runtime compiler
>     if we made this change in javac?
>
>     Thanks,
>     Paul
>