Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #15883

Re: Java processors

From Lew <noone@lewscanon.com>
Newsgroups comp.lang.java.programmer
Subject Re: Java processors
Date 2012-07-08 17:56 -0700
Organization albasani.net
Message-ID <jtda71$66j$1@news.albasani.net> (permalink)
References (12 earlier) <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>

Show all headers | 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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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