Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #15830
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Java processors |
| Date | 2012-07-05 16:42 -0500 |
| Organization | albasani.net |
| Message-ID | <jt51rg$hk5$1@news.albasani.net> (permalink) |
| References | <5f101d00-4bc9-4750-939c-cd53605bfa0e@googlegroups.com> <jt4bqi$c2b$1@dont-email.me> <jt4kr2$mdd$1@news.albasani.net> <jt4mht$glm$1@dont-email.me> |
On 7/5/2012 1:31 PM, Eric Sosman wrote: > 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. > well, yes, but it isn't clear how this is directly related (since it was JIT vs raw HW support, rather than about JIT vs compilation in advance). a limiting factor for JIT and optimizations is that they often have a much smaller time window, and so are limited mostly to optimizations which can themselves be performed fairly quickly. FWIW though, there is also AOT, which can also optimize specifically for a specific piece of hardware, but avoids a lot of the initial delay of a JIT by compiling in advance (or on first execution, so the first time the app will take a longer time to start up, but next time it will start much faster). yes, there are a lot of tradeoffs, for example, AOT will not be able to, say, make decisions informed by profiler output, since in this case it will not have this information available. > 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? > yeah. even then, there may be other levels of tradeoffs, such as, whether to do full compilation, or merely spit out some threaded code and run that. the full compilation then is much more complicated (more complex JIT), and also slower (since now the JIT needs to worry about things like type-analysis, register allocation, ...), whereas a simpler strategy, like spitting out a bunch of function calls and maybe a few basic machine-code fragments, is much faster and simpler (the translation can be triggered by trying to call a function, without too many adverse effects on execution time, and will tend to only translate parts of the program or library which are actually executed). some of this can influence VM design as well (going technically OT here): in my VM it led to the use of explicit type-tagging (via prefixes), partly because the bytecode isn't directly executed anyways (merely translated to threaded code by this point), and the "original plan" of using type-inference and flow-analysis in the JIT backend was just too much effort to bother with for the more "trivial" threaded-code backend, so I instead ended up migrating a lot of this logic to the VM frontend, and using prefixes to indicate types. I still call the threaded-code execution "interpretation" though, partly because it is a gray area and from what I can gather, such a thing is still called an interpreter even when it no longer bases its execution off direct interpretation of bytecode or similar. but, the threaded-code is at least sufficiently fast to lessen the immediate need for the effort of implementing a more proper JIT compiler. or such...
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Java processors bob smith <bob@coolfone.comze.com> - 2012-07-05 08:01 -0700
Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-05 11:28 -0400
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 13:00 -0500
Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-05 14:31 -0400
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 16:42 -0500
Re: Java processors Arne Vajhøj <arne@vajhoej.dk> - 2012-07-05 20:30 -0400
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 21:12 -0500
Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-06 00:13 -0400
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:26 -0700
Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-06 13:50 -0700
Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-06 14:17 -0700
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:07 -0700
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 09:34 -0500
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-07 21:01 -0700
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 00:28 -0500
Re: Java processors Lew <noone@lewscanon.com> - 2012-07-07 23:00 -0700
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 10:20 -0500
Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 09:16 -0700
Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-08 17:46 +0000
Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 11:52 -0700
Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-08 21:41 +0000
Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 17:56 -0700
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:44 -0700
Re: Java processors Lew <noone@lewscanon.com> - 2012-07-09 23:41 -0700
Re: Java processors David Lamb <dalamb@cs.queensu.ca> - 2012-07-16 13:22 -0400
Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-16 14:03 -0700
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:42 -0700
Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-10 01:13 +0200
Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-09 16:26 -0700
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-11 15:41 -0700
Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-12 01:02 +0200
Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-21 18:46 +0200
Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-21 13:05 -0400
Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-21 19:23 +0200
Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-21 14:10 -0400
Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-23 01:17 +0200
Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-22 20:15 -0400
Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-22 15:13 +0200
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:03 -0700
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:51 -0700
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-07 21:17 -0700
Re: Java processors Lew <noone@lewscanon.com> - 2012-07-07 23:04 -0700
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 09:29 -0700
Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 11:57 -0700
Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-08 15:40 +0200
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 10:36 -0500
Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-06 11:31 -0700
Re: Java processors Jim Janney <jjanney@shell.xmission.com> - 2012-07-05 13:02 -0600
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 16:09 -0500
Re: Java processors Jan Burse <janburse@fastmail.fm> - 2012-07-06 01:29 +0200
Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 00:42 +0000
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:53 -0700
Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 21:18 +0000
Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-06 18:17 -0400
Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 22:29 +0000
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:10 -0700
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 09:42 -0500
Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 10:58 -0400
(OT) Was: Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 11:38 -0400
Re: (OT) Was: Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-07 21:19 -0700
Re: (OT) Was: Re: Java processors "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-07-08 12:15 +0200
Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-07 21:17 -0700
Re: Java processors Jim Janney <jjanney@shell.xmission.com> - 2012-07-05 19:14 -0600
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:34 -0700
Re: Java processors Jan Burse <janburse@fastmail.fm> - 2012-07-06 23:04 +0200
Re: Java processors Silvio Bierman <silvio@moc.com> - 2012-07-07 00:13 +0200
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:16 -0700
Re: Java processors "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-07-08 11:37 +0200
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:24 -0700
Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 10:06 -0500
Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 05:22 -0700
csiph-web