Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #15883
| Path | csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail |
|---|---|
| From | Lew <noone@lewscanon.com> |
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Java processors |
| Date | Sun, 08 Jul 2012 17:56:08 -0700 |
| Organization | albasani.net |
| Lines | 94 |
| Message-ID | <jtda71$66j$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> <4ff6318d$0$283$14726298@news.sunsite.dk> <jt5okh$53a$1@dont-email.me> <9diev791cc84tsljqusgl14shpseba19o7@4ax.com> <djjev7565b8ctdboqn9t9h7nc0eqdu413m@4ax.com> <89ca24f7-0bf9-4d4b-be91-ef131989c4c9@googlegroups.com> <ma6fv7dr1u82acmp89ti4pjk3srnh3ts92@4ax.com> <jt9hjc$qin$1@news.albasani.net> <ac1iv7lue61ncqckd8dr1vau4oik8a17np@4ax.com> <jtb5vf$jjd$1@news.albasani.net> <jtb7lc$pk3$1@news.albasani.net> <jtch2b$m9u$1@localhost.localdomain> <jtcktv$i25$1@news.albasani.net> <jtcuqk$q15$1@localhost.localdomain> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=UTF-8; format=flowed |
| Content-Transfer-Encoding | 7bit |
| X-Trace | news.albasani.net qnGOeihvAP1UC2mkCAZPgytmRJheZPYNiadrG18U2k7fbX2gDse9hlG0BaeKW2UYzQD+DtUoZsKjV/7ndwL3zxT80jP4XUTcfTeUv1lSTkGQALWHK6zu1HxUVPCKPKDu |
| NNTP-Posting-Date | Mon, 9 Jul 2012 00:56:01 +0000 (UTC) |
| Injection-Info | news.albasani.net; logging-data="DZDuvJVFrJTafGZQgIEgMrajMDi0KyWxs6Fw2TGOb/qsazM+SoM2MOM16pUJcVSPikAjd9oG5vun1lGlDOfil8IaTeaVYQ9ARgwFK8WzY3DZ3YuGlM5zAmGyHKEr4z3L"; mail-complaints-to="abuse@albasani.net" |
| User-Agent | Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
| In-Reply-To | <jtcuqk$q15$1@localhost.localdomain> |
| Cancel-Lock | sha1:g2L7qRhdITeO6KjmrE4b/oSmrtI= |
| Xref | csiph.com comp.lang.java.programmer:15883 |
Show key headers only | View raw
Martin Gregorie wrote: > Lew wrote: >> Martin Gregorie wrote: >>> Lew wrote: >>>> HotSpot also will "unJIT" code - go back to the interpreted bytecode >>>> and drop the machine-code compilation - when circumstances change. >>>> >>> In view of this, why are we assuming that the JIT stops a method in its >>> tracks, compiles a native version and continues execution in that from >>> the stopping point? Are we sure that it doesn't do something along the >> >> "We"? >> >> I, at least, make no such assumption. >> > Fair enough: not you, but several here have been assuming that this > bytecode to native code switch occurs despite the obvious difficulties of > doing so. It's not the switch I don't assume, it's the "stop the bytecode" part, as I have now posted many times in this thread. I'm also not assuming anything at all, because I am simply repeating what is in the documentation. I'm not spouting "it is likely that" stuff off the top of my head without looking up the citations I've provided. Furthermore I've been going back and reading the documentation as we discuss this matter. Perhaps I am alone in this practice? Those making unfounded assumptions could resolve their confusion by reading the available literature. Then instead of assumptions and "it is likely that" supposition, one would have certain knowledge and conclusions. >> As I understand the white papers, HotSpot, at least, does not stop the >> interpreter while it's compiling, but does background compilation. >> > I wondered about this, but as it could cause potential conflicts if JIT > compilation takes significantly longer than interpreted execution of the > code section (the normal case?), described a stopping scenario because it > can't cause that sort of problem. Apparently it does not cause conflicts, as the HotSpot folks repeatedly tell us that they do this with no harm at all to program semantics. In fact, the point you raise is the motivation to have compilation occur concurrently with interpreted execution. The fact that it takes a while to analyze for hot spots, much less compile them, is relevant to the fact that HotSpot takes a while to analyze for hot spots, much less compile them. Doing it in the background gives it the freedom to take that while. >> I don't have a reference handy just now, but HotSpot does do something >> like the flip you describe, save for the "stopping bytecode" part, IIRC. >> > Interesting. If recompilation is needed, is more than one recompiled > version kept at a time or does the system switch back to bytecode while > the recompilation runs? Is there any data on the frequency of The latter. It wouldn't make sense to keep old compilations around. They're based on runtime conditions that by definition have changed or the old one would still be valid. There is no way for the system to predict if those same runtime conditions will pertain in the future, nor that it would be worth the memory and analytical power to decide if it did, since such analysis is the larger part of HotSpot compilation to begin with. In any event, the white paper to which I linked and other sources talk about simply dropping the compiled code and going back to interpreted until the spot gets hot enough again to recompile it. > recompilation vs the initial JIT pass? If its quite infrequent, then HotSpot is not a JIT compiler. > temporary reversion to bytecode may be a worthwhile strategy, especially It might be permanent, that reversion. > if the recompilation isn't restricted to exactly the same set of bytecode > instructions. It isn't, nor is it guaranteed to occur for anything close to that same set again. And it's not just the instructions. It's the runtime profile, such as whether other threads are active for the critical section, or there are aliases for key references, or whether they escape the current context just now, or ... Plus it only applies to sections of code that the internal profiler reveals to matter, the eponymous hot spots. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
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