Re: Java processors
On 7/5/2012 2:00 PM, BGB wrote:
On 7/5/2012 10:28 AM, Eric Sosman wrote:
On 7/5/2012 11:01 AM, bob smith wrote:
What ever happened to those processors that were supposed to run Java
natively?
Did Sun or anyone else ever make those?
http://en.wikipedia.org/wiki/Java_processor
(If you need help clicking links, just ask.)
and, of those, AFAIK, ARM's Jazelle was the only one to really gain much
widespread adoption, and even then is largely being phased out in favor
of ThumbEE, where the idea is that instead of using direct execution, a
lightweight JIT or similar is used instead.
part of the issue I think is that there isn't really all that much
practical incentive to run Java bytecode directly on a CPU, since if
similar (or better) results can be gained by using a JIT to another ISA,
why not use that instead?
this is a merit of having a bytecode which is sufficiently abstracted
from the underlying hardware such that it can be efficiently targeted to
a variety of physical processors.
this is in contrast to a "real" CPU ISA, which may tend to expose enough
internal workings to where efficient implementation on different CPU
architectures are problematic (say: differences in endianess, support
for unaligned reads, different ways of handling arithmetic status
conditions, ...). in such a case, conversion from one ISA to another may
come at a potentially significant performance hit.
whereas if this issue does not really apply, or potentially even the
output of the JIT will execute faster than it would via direct execution
of the ISA by hardware (say, because the JIT can do a lot more advanced
optimizations or map the code onto a different and more efficient
execution model, such as transforming the stack-oriented code into
register-based machine code), than there is much less merit to the use
of direct execution.
In principle, a JIT could do better optimization than a
traditional compiler because it has more information available.
For example, a JIT can know what classes are actually loaded in
the JVM and take shortcuts like replacing getters and setters with
direct access to the underlying members. A JIT can gather profile
information from a few interpreted executions and use the data to
guide the eventual realization in machine code. Basically, a JIT
can know what the environment actually *is*, while a pre-execution
compiler must produce code for every possible environment.
On the other hand, a former colleague of mine once observed
that "Just-In-Time" is in fact a misnomer: it's a "Just-Too-Late"
compiler because it doesn't even start work until after you need
its output! Even if the JIT generates code better optimized for
the current circumstances than a pre-execution compiler could,
the JIT's code starts later. Does Achilles catch the tortoise?
--
Eric Sosman
esosman@ieee-dot-org.invalid