Smaller byte code for small constants

Paul Govereau paul.govereau at
Sat Sep 13 01:29:08 UTC 2014

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
> <mailto:paul.govereau at>> 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

More information about the compiler-dev mailing list