Re: Facts about the Java class file format

[Posted and mailed]


In article 98-10-129,
Tim Harris <tlh20@cam.ac.uk> writes:


[...]
> Something else that came to mind while reading the report is whether
> there is much to be gained by analyzing the values which occur as
> operands to bytecode operations -- for example whether there is a useful
> dominance of low values produced by aload/iload/etc.


We have a student here doing this analysis as part of his master thesis.


> [It also occurs to me that small size is important when you're
> transferring a Java app, but less important when you're running it.
> Netscape ships their Java code in zip files, where it's typically
> compressed by about 50%. How much better than that is anyone likely
> to do and still have a format that's useful for execution? -John]


We do not know yet how much better you can get. However, the class
file is clearly the external representation of a compiled Java class
and must not reflect the internal representation used by the virtual
machine, as long the external representation can be translated
efficiently into the internal form at load time. We think that the
actual class file format too much reflects the internal representation
and is not enough optimized for small size. We are exploiting a couple
of optimizations, namely


  o more compact encoding of the constant pool
  o more compact encoding of instructions
  o pack multiple class files together and store the same information only
      once.
  o store secondary information in additional files and load it only
      on demand (e.g. debug information, native code)


Greetings, Markus


--
  email: pilz@ifi.unizh.ch Markus Pilz, University of Zurich
  voice: +41-1-635 67 12 Department of Computer Science
  fax: +41-1-635 68 09 Winterthurerstr. 190, CH-8057 Zurich
  www: http://www.ifi.unizh.ch/~pilz

Return to the comp.compilers page.
Search the comp.compilers archives again.