Smaller byte code for small constants

[Vitaly Davidovich]

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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140912/a58eb914/attachment-0001.html>