On Dec 2, 2015, at 5:24 AM, Claes Redestad <claes.redes...@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.
