Smaller byte code for small constants
paul.govereau at oracle.com
Sat Sep 13 01:29:08 UTC 2014
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
> However, we could save ourselves a constant pool slot with:
> bipush 3
> 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?
More information about the compiler-dev