Re: Facts about the Java class file format

Since nobody else has mentioned this yet...
\"Markus Pilz\ (pilz@ifi.unizh.ch) wrote:
: [Posted and mailed]
: 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]


There is a fascinating article in the latest Microprocessor
Report about an IBM POWER (or possibly PowerPC) implementation that
_executes_ compressed binaries, de-compressing as it loads them into
the moral equivalent of I-cache lines. I have passed on my copy by
now, but IIRC, they alleged something like 40% compression.


Not that this has much to do with Java class file formats, but
until a few days ago I would have held the opinion that this was a
thoroughly mad idea. Of course, It may yet be. The same issue has a
good article on the AMD K7, which is fascinating. Again, perhaps a
failure of imagination on my part, but if someone had come up to me in
1972, when I was mucking about with 8008s, and had said that 26 years
hence, a contendor for "fastest CPU" would be a clearly recognizable
descendant of that machine, implemented so as to have up to 72
partially completed instruction "in flight" through three execution
units, and would run at 300+ MHz, I'd have suggested therapy. So maybe
IBM is on to something...


: [..] 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.


Look into that article. "load time" may mean something closer
to execution time than you have in mind :-)


Mike
| albaugh@agames.com, speaking only for myself
[It's my impression that fast CISC CPUs like the later Vaxes and
Pentiums translate the instruction stream into fixed size instructions
in the instruction buffer. The Multiflow machines also used a
compressed format unpacked as fetched because its instructions were
large and sparse. But hmmn, CPUs faster than memory, instruction
fetch is a bottleneck, it's 1972 all over again, time to reinvent the
Vax. -John]

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