Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Java processors Date: Thu, 05 Jul 2012 14:31:21 -0400 Organization: A noiseless patient Spider Lines: 65 Message-ID: References: <5f101d00-4bc9-4750-939c-cd53605bfa0e@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 5 Jul 2012 18:31:25 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="03ebLEozl+tXCe7JS60Feg"; logging-data="17078"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19uYYF/XfFgMm5h9+APmwlq" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: Cancel-Lock: sha1:JvfHeXLhppNHKzzwdqApKMsbbMU= Xref: csiph.com comp.lang.java.programmer:15824 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