Enhance footprint for array initialization

[Ulf Zibis]

Am 02.09.2008 17:32, Tom Rodriguez schrieb:
> I think you're on the wrong list.  This is a javac code generation 
> issue.  I think you want compiler-dev at openjdk.java.net.
>
> tom
>
Hi tom,

 >From the 1st view, you are right, javac list would be better, but 
knowledge about bytecode should exist in both lists, and I wanted to 
avoid to subscribe to an additional list.
 >From the 2nd view, my question is about if there is any reasonably 
way, a data table will be recognized in bytecode from the VM. If yes, 
the javac guys should be asked, to compile such tables to bytecode. If 
not, my post should be interpreted as an RFE to the VM guys to provide 
such a class file format.

Especially this question is *not* about performance as you might have 
thought, it's about footprint of the class files. Performance here is 
not important, because as static initialisation this code is only 
executed once, so it isn't reasonable to Hotspot to optimize it first. 
Think about the charset.jar in JDK. Its about more than 6 MBytes, full 
with repeating bytecode just for initializing static encoding tables. It 
could be much smaller.

I'm worried the amount of bytecode instructions, needed to initialize a 
static array. I first thought, there must be a new bytecode to define 
table date, which could look like:

static {};
  Code:
   0:    tabledef    950  // Start of table for 16-bit values, length 
950, containing the pointers to the String constants
   3:    #39; //String 8859_1
   5:    #40; //String ISO8859_1
   7:    #115; //String iso_8859-1:1987
   9:    #40; //String ISO8859_1
   11:   // ...

Yesterday I gave me 1 day, to study the VM Specification more deeper. So 
I came to the conclusion, that there is missing an array-type for the 
Constant Pool 
<http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#20080> 
in the class file format. This would reduce the footprint of class files 
significantly, because the repeated codes to initialize long arrays 
could be omitted.
More worse it looks for byte arrays, than for string arrays:

private static final byte[] allBytes = {

        (byte)0x00, (byte)0x01, (byte)0x02,
        // .....        
                                (byte)0xFF, (byte)0xFF
}

The bytecode will look like (256 times):
 40:  dup
 41:  bipush 8
 43:  bipush 8
 45:  bastore

So the class file will need 6 times more footprint, than a simple 
"CONSTANT_array".

Hopefully you now understand better the subject of my post,

Regards,
Ulf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080903/6bfdc7e6/attachment.html