Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Java processors Date: Sun, 8 Jul 2012 17:46:51 +0000 (UTC) Organization: UK Free Software Network Lines: 22 Message-ID: References: <5f101d00-4bc9-4750-939c-cd53605bfa0e@googlegroups.com> <4ff6318d$0$283$14726298@news.sunsite.dk> <9diev791cc84tsljqusgl14shpseba19o7@4ax.com> <89ca24f7-0bf9-4d4b-be91-ef131989c4c9@googlegroups.com> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1341769611 22846 84.45.235.129 (8 Jul 2012 17:46:51 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Sun, 8 Jul 2012 17:46:51 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: csiph.com comp.lang.java.programmer:15878 On Sat, 07 Jul 2012 23:00:13 -0700, 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 lines of stopping the bytecode execution (as above) doing a JIT native compilation and, when its finished, wrap both the bytecode version and the native binary versions in a switch mechanism, set the version selector to 'native' and then restart the bytecode version? Something like this would sidestep the wherethefugarwi problem of stopping bytecode and restarting in optimised native binary while making sure that the *next* execution run the JITed native binary. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |