Smaller byte code for small constants

[John Rose]

On Sep 12, 2014, at 11:39 AM, 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?

As Vitaly points out, inlining heuristics depend on metrics which these tricks affect.

Inflating a metric is risky for that reason, whether the metric is bytecode size (same here) or bytecode instruction count (larger) or classfile size (smaller).

The differences in interpreter execution are negligible.  The JIT IR generated will be the same, almost certainly.

Here's a tie-breaker principle:  The more complex you make the class file, the less pattern-based optimizations will apply reliably.

Put another way, upstream optimizers confuse downstream optimizers, if they are looking for the same things.

This is true for both compressors and code optimizers and probably other things.  It adds a reason to keep things straightforward.

— John