Re: Byte array
markspace wrote:
Thomas Pornin wrote:
However, this results in an easily recognizable bytecode pattern which
any compiler (whether JIT or AOT) can easily recognize as such and
transform into a mass initialization
<snip>
"bastore". Hence, 4 to 11 bytecode bytes for each value byte. However,
.class are compressed and the Deflate algorithm which is used in Jar
files is prone to detect and exploit the redundancy of the pattern.
Just curious: do you have any evidence that the Java compiler does this
operations? I really am curious. It would be neat if it did.
The javac compiler doesn't compress, and doesn't do much in the
way of optimization: It emits the bytecode as Thomas describes it,
just plugging away at the successive assignments. You can use the
javap utility to disassemble the bytecode and study it for yourself.
If you put the resulting .class file in a .jar (which is just
a .zip archive that obeys some conventions), it gets compressed in
the usual .zip ways. Again, it's easy for you to investigate for
yourself: open up the .jar with a .zip tool (you might need to
rename it first), and compare the size of the compressed .class
archive entry with the original uncompressed .class file to
assess how effective the compression is.
Finally, there's the question of what the JVM does with the
bytecodes when it loads and executes the class. I don't think it
can take any shortcuts during bytecode validation, and JITting
might actually be a waste of effort if the code runs just once.
I don't know how to investigate what goes on inside the JVM --
there's a java.lang.instrument package whose name sounds promising,
but I've never used it myself and don't know what you can get it
to do.
Another way would be to store the bytes as a literal string. Any byte
value can be converted to an octal sequence "\xyz". At runtime, the
Resulting in an 80k string. No, I think I'd prefer a 20k binary file,
which is then loaded as a resource. I know that's as "compressed" as it
can possibly.
I think you can get down to a 20KB string by using \uXXXX to
encode two byte values in each "character." Of course, you're
still stuck with the String as an intern'ed literal even after
you've extracted its contents into a byte[]. (Well, I guess you
could get rid of it by using a special ClassLoader to load the
class that generates the byte[], ... but now we're starting to
take heroic measures just for heroism's sake.)
Loading from a resource is the approach I'd recommend. If
nothing else, it means you can eliminate all that clumsy manual
reformatting. Once you've hiccuped a few times in the copy-and-
paste steps, omitting a line somewhere or copying the same line
twice, the value of the more automatic approach will start to
make itself manifest ...
--
Eric.Sosman@sun.com