Re: Java processors
BGB wrote:
Lew wrote:
HotSpot and other Java JIT compilers have an advantage over static
optimizers such as you describe - they can account for current run-time
conditions.
For example, it might be that none but one thread are using a section of
code so all synchronization operations can be removed for a while.
Or perhaps there are no aliases extant for a given member variable, so
it is safe to enregister the value for a while, even though statically
it would not be safe.
HotSpot also will "unJIT" code - go back to the interpreted bytecode and
drop the machine-code compilation - when circumstances change.
I wasn't focusing solely on static compilers, as a lot of this applies to JIT
compilers as well.
yes, but the question would be how many of these would risk compromising the
ability of the VM to readily switch between the JIT output and bytecode.
None of them.
very possibly, the JIT would be focusing more on optimizations which would not
hinder its own operation.
None of the optimizations it does hinder its own operation, so that's
trivially true.
an example would be maintaining "sequential consistency", where theoretically,
an optimizer would alter the relative order in which operations take place, or
reorganize the control flow within a method, ...
You explained the other use of quotation marks quite well. What is the intent
of these here?
The optimizer does, indeed, alter the naive order of operations as it deems
helpful, according to what I've read.
It does so, when it does so, in a way that does not break the observed order
of events as mandated by the JLS.
although possible, this would hinder the ability to easily jump into or out-of
the JITed output code, so a JIT would likely refrain from doing so (upholding
the behavior that events take place in the native code in the same relative
order as they appear in the bytecode, ...).
The compiler avoids breaking the promise mandated by the JLS. It does not bind
itself further than that with respect to altering the order of events.
When you say "likely", how likely and on what are you basing your probability
estimate?
It is 100% certain that the optimizer doesn't break the promise of execution
order mandated by the JLS. It has nothing to do with jumping into or "out-of
[sic]" native code. It has to do with maintaining mandatory program semantics.
The optimizer cheerfully rearranges execution order in ways that do not
violate the promise, when it finds it advantageous to do so. I do not know how
to estimate the probability of that happening, except that documentation
claims that it does sometimes happen.
very likely, the JIT would also arrange that the overall state is consistent
at points where it may jump into or out of the generated code (all values
properly stored in their respective variables, ...).
Again with the "very likely". How likely is that? Based on what evidence?
--
Lew
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg