|Facts about the Java class file format firstname.lastname@example.org (Markus Pilz) (1998-10-17)|
|Re: Facts about the Java class file format email@example.com (Tim Harris) (1998-10-21)|
|Re: Facts about the Java class file format jgm@CS.Cornell.EDU (Greg Morrisett) (1998-10-24)|
|Re: Facts about the Java class file format firstname.lastname@example.org (Stefan Monnier) (1998-10-30)|
|Re: Facts about the Java class file format Jan.Vitek@cui.unige.ch (1998-10-30)|
|Re: Facts about the Java class file format email@example.com (1998-10-30)|
|Re: Facts about the Java class file format firstname.lastname@example.org (1998-11-01)|
|Re: PowerPC CodePack (Was: Facts about the Java class file format) email@example.com (1998-11-06)|
|Re: PowerPC CodePack (Was: Facts about the Java class file format) firstname.lastname@example.org (1998-11-08)|
|Re: PowerPC CodePack (Was: Facts about the Java class file format) email@example.com (Jean-Francois Brouillet) (1998-11-08)|
|Re: PowerPC CodePack (Was: Facts about the Java class file format) firstname.lastname@example.org (1998-11-12)|
|From:||email@example.com (Mike Albaugh)|
|Date:||1 Nov 1998 11:46:40 -0500|
|Organization:||Atari Games Corporation|
|References:||98-10-108 98-10-129 98-10-171|
Since nobody else has mentioned this yet...
\"Markus Pilz\ (firstname.lastname@example.org) wrote:
: [Posted and mailed]
: Tim Harris <email@example.com> 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 :-)
| firstname.lastname@example.org, 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
Return to the
Search the comp.compilers archives again.