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

Groups > comp.lang.java.programmer > #15821 > unrolled thread

Java processors

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 1 of 4  [1] 2 3 4  Next page →

#15821 — Java processors

What ever happened to those processors that were supposed to run Java natively?

Did Sun or anyone else ever make those?  

[toc] | [next] | [standalone]

#15822

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.)


-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15823

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.

[toc] | [prev] | [next] | [standalone]

#15824

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.

     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?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15830

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...

[toc] | [prev] | [next] | [standalone]

#15833

On 7/5/2012 2:31 PM, Eric Sosman wrote:
>      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?

It is my impression that modern JVM's especially with -server
(or equivalent) is rather aggressive about JIT compiling.

.NET CLR always does it first time I believe.

Arne

[toc] | [prev] | [next] | [standalone]

#15836

On 7/5/2012 7:30 PM, Arne Vajhøj wrote:
> On 7/5/2012 2:31 PM, Eric Sosman wrote:
>>      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?
>
> It is my impression that modern JVM's especially with -server
> (or equivalent) is rather aggressive about JIT compiling.
>
> .NET CLR always does it first time I believe.
>

yes, but also .NET CIL is not really well suited to direct 
interpretation (the bytecode does not itself contain full type 
information, ...), with the idea being that JIT is the sole "viable" way 
to execute it.

so, when starting up a program, the .NET CLR will compile it to native 
code, and then begin executing it.


also, very often .NET programs are AOT compiled during or shortly 
following installation (if one observes a heavy CPU usage of "ngen.exe", 
during or following installation of a .NET app, that is the AOT compiler 
doing its thing).

[toc] | [prev] | [next] | [standalone]

#15837

On 7/5/2012 8:30 PM, Arne Vajhøj wrote:
> On 7/5/2012 2:31 PM, Eric Sosman wrote:
>>      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?
>
> It is my impression that modern JVM's especially with -server
> (or equivalent) is rather aggressive about JIT compiling.

     My colleague's point was that JITting the code, aggressively
or not, is pre-execution overhead: It is work spent on something
other than running your code.  If you just dove in and started
interpreting you might be running more slowly, but you'd have a
head start: Achilles is the faster runner, but cannot overcome
the tortoise's lead if the race is short.

     I dunno: Are JIT's nowadays smart enough to recognize code
that will (future tense) execute too few times to be worth JITting?
Static initializers without loops, say?  Code in (some) catch
blocks?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15841

On Fri, 06 Jul 2012 00:13:00 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
someone who said :

>If you just dove in and started
>interpreting you might be running more slowly, but you'd have a
>head start

That is just what JITs do. It is only after a while they have gathered
some stats to they decide which classes to turn to machine code. The
astounding thing is they stop the interpreter in mid flight executing
a method, and replace it with machine code and restart it. That to me
is far more impressive than walking on water.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15843

On Fri, 06 Jul 2012 13:26:58 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

>On Fri, 06 Jul 2012 00:13:00 -0400, Eric Sosman
><esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
>someone who said :
>
>>If you just dove in and started
>>interpreting you might be running more slowly, but you'd have a
>>head start
>
>That is just what JITs do. It is only after a while they have gathered
>some stats to they decide which classes to turn to machine code. The
>astounding thing is they stop the interpreter in mid flight executing
>a method, and replace it with machine code and restart it. That to me
>is far more impressive than walking on water.

     Do you have a cite for that?  Restarting a method could be messy.
Imagine if files are opened, other objects created, etc.

     I suspect that it might be as prosaic as a method execution times
counter reaching a threshold value triggering the conversion.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15846

Gene Wirchenko wrote:
> Roedy Green wrote:
>>Eric Sosman wrote, quoted or indirectly quoted someone who said :
>>> If you just dove in and started
>>> interpreting you might be running more slowly, but you'd have a
>>> head start
>>
>> That is just what JITs do. It is only after a while they have gathered
>> some stats to they decide which classes to turn to machine code. The
>> astounding thing is they stop the interpreter in mid flight executing
>> a method, and replace it with machine code and restart it. That to me
>> is far more impressive than walking on water.

They don't do that exactly. There's no restart.

<http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_warmup>
 
>      Do you have a cite [sic] for that?  Restarting a method could be messy.

This was in the links I provided upthread.

> Imagine if files are opened, other objects created, etc.
> 
>      I suspect that it might be as prosaic as a method execution times
> counter reaching a threshold value triggering the conversion.

Also cited upthread. I don't know that it's method-by-method; I 
think HotSpot optimizes at finer granularity than that. The cited 
reference refers to optimizing "loops".

But it's far from prosaic. The HotSpot compiler (not to be confused with 
other JIT compilers) can switch to native-compiled code mid-execution 
while the interpreted code is running. Given that the compiler is 
aware of run-time circumstances, I don't know that it would need to 
have trouble with file handles and the sorts of things you mention.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15853

On Fri, 6 Jul 2012 14:17:40 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>
>They don't do that exactly. There's no restart.
>
><http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_warmup>

" HotSpot contains On Stack Replacement technology which will compile
a running (interpreted) method and replace it while it is still
running in a loop. No need to waste your applications time warming up
seemingly infinite (or very long running) loops in order to get better
application performance."

It thus stops it is mid flight, possibly half way through a loop,
writes machine code, creates the equivalent state/register, and picks
up where it left off (what I ambiguously called restarting) but
running machine code.  I can hardly believe this is possible,
especially when you think about all the optimisations on the machine
code.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15858

On 7/6/2012 9:07 PM, Roedy Green wrote:
> On Fri, 6 Jul 2012 14:17:40 -0700 (PDT), Lew <lewbloch@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>>
>> They don't do that exactly. There's no restart.
>>
>> <http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_warmup>
>
> " HotSpot contains On Stack Replacement technology which will compile
> a running (interpreted) method and replace it while it is still
> running in a loop. No need to waste your applications time warming up
> seemingly infinite (or very long running) loops in order to get better
> application performance."
>
> It thus stops it is mid flight, possibly half way through a loop,
> writes machine code, creates the equivalent state/register, and picks
> up where it left off (what I ambiguously called restarting) but
> running machine code.  I can hardly believe this is possible,
> especially when you think about all the optimisations on the machine
> code.
>

actually, it wouldn't likely be all that difficult assuming that both 
forms use comparable data representations and ABIs, and the optimizer 
retains sequential consistency.

in the sequential-consistency case, there is likely to still be a 
mapping between the bytecode instructions and their equivalent 
machine-code sequences, so once the JIT does its thing, and any state is 
copied over, then a jump is made to the analogous location in the 
machine code.


(can't claim to be any expert on HotSpot though, and most of my personal 
experience has been with function/method at a time JITs, where likely a 
method would be JITed after being called N times).

[toc] | [prev] | [next] | [standalone]

#15863

On Sat, 07 Jul 2012 09:34:52 -0500, BGB <cr88192@hotmail.com> wrote,
quoted or indirectly quoted someone who said :

>in the sequential-consistency case, there is likely to still be a 
>mapping between the bytecode instructions and their equivalent 
>machine-code sequences, so once the JIT does its thing, and any state is 
>copied over, then a jump is made to the analogous location in the 
>machine code.

Now throw in this complication. The JIT decided to convert
multiplication inside the loop to addition. There potentially needs to
be a fixup corresponding to each optimisation.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15868

On 7/7/2012 11:01 PM, Roedy Green wrote:
> On Sat, 07 Jul 2012 09:34:52 -0500, BGB <cr88192@hotmail.com> wrote,
> quoted or indirectly quoted someone who said :
>
>> in the sequential-consistency case, there is likely to still be a
>> mapping between the bytecode instructions and their equivalent
>> machine-code sequences, so once the JIT does its thing, and any state is
>> copied over, then a jump is made to the analogous location in the
>> machine code.
>
> Now throw in this complication. The JIT decided to convert
> multiplication inside the loop to addition. There potentially needs to
> be a fixup corresponding to each optimisation.
>

there are all sorts of optimizations which could break the simple case, 
but what is to say that the JIT actually uses these optimizations in 
these cases? (rather than limiting itself solely to "reasonably safe" 
optimizations in such cases).

or, alternatively, it could just mark the point where it will jump into 
the code as a "synchronized label" or simiar, so regardless of what 
sorts of optimizations are used elsewhere, everything is "consistent" at 
the location where it will jump into the JITed code (at the potential 
cost of a register spill just before this entry point for all subsequent 
executions, ...).

but, absent more information, it starts to get pointless to speculate.


but, hell, with certain compilers (*cough* MSVC *cough*), it is an 
optimization setting mostly to have it cache the values of variables in 
registers (much less anything much more advanced that this).

caching variables in registers and using basic peephole optimizations 
actually goes a long ways towards generating "optimized" compiler output.

many other (potentially more significant) optimizations are 
higher-level, and don't necessarily actually make much of a difference 
at the lower-levels.

...

[toc] | [prev] | [next] | [standalone]

#15869

BGB wrote:
> but, hell, with certain compilers (*cough* MSVC *cough*), it is an

I know. Kinda makes ya gag just to mention it, doesn't it?

> optimization setting mostly to have it cache the values of variables in
> registers (much less anything much more advanced that this).

That is rather oversimplifying the optimization options available.

> caching variables in registers and using basic peephole optimizations actually
> goes a long ways towards generating "optimized" compiler output.

What do you mean by the quotation marks?

How long is a "long ways" and compared to what?

> many other (potentially more significant) optimizations are higher-level, and
> don't necessarily actually make much of a difference at the lower-levels.

What do you mean by "higher-level" and "lower-levels [sic]"?

Of which particular optimizations do you speak?

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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#15874

On 7/8/2012 1:00 AM, Lew wrote:
> BGB wrote:
>> but, hell, with certain compilers (*cough* MSVC *cough*), it is an
>
> I know. Kinda makes ya gag just to mention it, doesn't it?
>

well, I actually use MSVC, but using MSVC and knowing ASM can make one 
not exactly all that impressed with its ASM output.


>> optimization setting mostly to have it cache the values of variables in
>> registers (much less anything much more advanced that this).
>
> That is rather oversimplifying the optimization options available.
>

it is very minimal, but this is what you get with basic optimization 
options with MSVC.

AFAICT, these ones are on by default (without explicit optimization 
settings), with GCC.

it is also a little annoying that it can't use optimization and 
profile/debug settings at the same time.


however, there are a few merits:
it has full access to the Windows API;
it has Visual Studio;
it can do .NET stuff;
...

my 3D engine is also mostly GPU-bound, so being compiled with debug 
settings doesn't really the hurt overall performance too badly.


>> caching variables in registers and using basic peephole optimizations
>> actually
>> goes a long ways towards generating "optimized" compiler output.
>
> What do you mean by the quotation marks?
>

these are actually fairly naive optimizations, compared with what is 
possible.

their relative effectiveness implies either:
many commonly used compilers are not very good on this front;
more advanced optimizations tend not to actually buy a whole lot (it 
more amounting to a case of diminishing returns).


was going to give an example from another area, but it turned out to be 
awkwardly long: basically, pointing out the cost/benefit tradeoffs which 
lead to the present near-dominance of Huffman compression over 
Arithmetic Coding and High-Order context modeling (PAQ / PPMd / ...), 
despite Huffman not compressing nearly as well.

although, to be fair, many more recent codecs (LZMA, H.264, ...) use AC, 
so things may be shifting slightly in its favor (the added compression 
outweighing the higher time-cost).

but, yeah, there is often a lot more that could be done, except that the 
costs may make it unreasonable or impractical to do so.


> How long is a "long ways" and compared to what?
>

    0x40d0cc   1252         obuf[l0+0]=r0; obuf[l0+1]=g0; obuf[l0+2]=b0; 
obuf[l0+3]=a;    0.68
    0x40d0cc    mov eax,[ebp-54h]              8B 45 AC     0.07
    0x40d0cf    add eax,[ebp-10h]              03 45 F0
    0x40d0d2    mov cl,[ebp-78h]               8A 4D 88
    0x40d0d5    mov [eax],cl                   88 08  0.07
    0x40d0d7    mov edx,[ebp-54h]              8B 55 AC     0.02
    0x40d0da    add edx,[ebp-10h]              03 55 F0
    0x40d0dd    mov al,[ebp-14h]               8A 45 EC     0.04
    0x40d0e0    mov [edx+01h],al               88 42 01
    0x40d0e3    mov ecx,[ebp-54h]              8B 4D AC     0.01
    0x40d0e6    add ecx,[ebp-10h]              03 4D F0     0.08
    0x40d0e9    mov dl,[ebp-08h]               8A 55 F8     0.02
    0x40d0ec    mov [ecx+02h],dl               88 51 02
    0x40d0ef    mov eax,[ebp-54h]              8B 45 AC     0.11
    0x40d0f2    add eax,[ebp-10h]              03 45 F0     0.01
    0x40d0f5    mov cl,[ebp-28h]               8A 4D D8     0.16
    0x40d0f8    mov [eax+03h],cl               88 48 03     0.09

compiler = MSVC, source language = C.


it can actually get a lot worse than this, but it illustrates the basic 
idea (without being too long).


for example, what if the compiler cached intermediate values in registers?
more likely the output above would look something more like:
mov eax,[ebp-54h]
add eax,[ebp-10h]
mov cl,[ebp-78h]
mov [eax],cl
mov dl,[ebp-14h]
mov [eax+01h],dl
mov cl,[ebp-08h]
mov [eax+02h],cl
mov dl,[ebp-28h]
mov [eax+03h],dl



>> many other (potentially more significant) optimizations are
>> higher-level, and
>> don't necessarily actually make much of a difference at the lower-levels.
>
> What do you mean by "higher-level" and "lower-levels [sic]"?
>
> Of which particular optimizations do you speak?
>

higher-level:
constant folding;
object lifetime analysis;
ability to skip out on certain safety checks;
scope visibility analysis and type-inference (mostly N/A to Java, more 
relevant to languages like ECMASript);
...

lower-level:
register allocation strategies;
peephole optimization;
...


higher-level optimizations can be done usually in advance of generating 
the output code, and they don't particularly depend on the type of 
output being produced (target architecture, ...).

whereas things like register allocation depend much more on the target 
architecture, and are more closely tied to the compiler output being 
produced.


> 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.

very possibly, the JIT would be focusing more on optimizations which 
would not hinder its own operation.

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, ...

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, ...).

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, ...).

[toc] | [prev] | [next] | [standalone]

#15876

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

[toc] | [prev] | [next] | [standalone]

#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       |

[toc] | [prev] | [next] | [standalone]

#15879

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.

> 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.

As I understand the white papers, HotSpot, at least, does not stop the 
interpreter while it's compiling, but does background compilation.

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.

HotSpot is not a JIT compiler, as they go through some pains to emphasize. 
It's an after-the-fact compiler.

<http://www.oracle.com/technetwork/java/whitepaper-135217.html#3>
"The compiler must not only be able to detect when these optimizations become 
invalid due to dynamic loading, but also be able to undo or redo those 
optimizations during program execution, even if they involve active methods on 
the stack. This must be done without compromising or impacting Java 
technology-based program execution semantics in any way."

"[T]he Java HotSpot VM immediately runs the program using an interpreter, and 
analyzes the code as it runs to detect the critical hot spots in the program. 
Then it focuses the attention of a global native-code optimizer on the hot spots."

"Dynamic Deoptimization"
<http://www.oracle.com/technetwork/java/whitepaper-135217.html#dynamic>

"Compiler Optimizations"
<http://www.oracle.com/technetwork/java/whitepaper-135217.html#optimizations>

"... the Server VM performs extensive profiling of the program in the 
interpreter before compiling the Java bytecode to optimized machine code. This 
profiling data provides even more information to the compiler about data types 
in use, hot paths through the code, and other properties. The compiler uses 
this information to more aggressively and optimistically optimize the code in 
certain situations. If one of the assumed properties of the code is violated 
at run time, the code is deoptimized and later recompiled and reoptimized."

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web