RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character

[John Rose]

On Dec 2, 2015, at 5:24 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Picking up this tiny improvement again, I realized there are a few other bytecode minifying tricks we could consider while we're at it:
> 
> http://cr.openjdk.java.net/~redestad/8143127/webrev.02/ <http://cr.openjdk.java.net/~redestad/8143127/webrev.02/>

Ah, constant-generation code.  Need I point out that this is a deliciously slippery slope?

For example, (1L << N) can be generated in 3-4 bytes with no constant pool entry.
An arbitrary int or long can be composed without a CP entry; there's a bewildering
range of more specialized patterns that would be more compact than burning a
CP entry.  Remember that CP entries are a limited resource; there are at most 2^16.

I'm *not* saying we should go down that slope any further.

— John

P.S. Full disclosure:  I have spent many happy hours obsessing about the corresponding
problem for SPARC.

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/cpu/sparc/vm/macroAssembler_sparc.cpp#l957

There's a lot you can do with shifts and xors, inside a 5-instruction budget.
For example, long strings of the same bit value are easy to materialize.
So are larger repeated patterns.