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

Did Sun or anyone else ever make those?  

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

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.

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

BGB <cr88192@hotmail.com> writes:

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

The cost of entry into CPU manufacturing is far from cheap, and once
you're in it's anything but a level playing field.  Intel has an
enormous advantage due to the amount of money it can plow into improving
its manufacturing processes.  And the demand for a system that can only
run JVM-based software is relatively limited.

Back in the day Niklaus Wirth had a system that was optimised for
running Modula-2, with its own processor and operating system written in
Modula-2.  I don't remember now what it was called.

-- 
Jim Janney

On 7/5/2012 2:02 PM, Jim Janney wrote:
> BGB <cr88192@hotmail.com> writes:
>
>> 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?
>
> The cost of entry into CPU manufacturing is far from cheap, and once
> you're in it's anything but a level playing field.  Intel has an
> enormous advantage due to the amount of money it can plow into improving
> its manufacturing processes.  And the demand for a system that can only
> run JVM-based software is relatively limited.
>
> Back in the day Niklaus Wirth had a system that was optimised for
> running Modula-2, with its own processor and operating system written in
> Modula-2.  I don't remember now what it was called.
>

yes, but ARM already had direct JBC execution in the form of Jazelle, 
which it is then phasing out in favor of ThumbEE, which is a JIT-based 
strategy.

I suspect this is telling, IOW, that even when one *can* directly 
execute on raw hardware, does it actually buy enough to make it worthwhile?

these occurrences imply a few things: Java is a fairly big thing on ARM, 
and even then it was likely either not sufficiently performance or 
cost-effective to keep direct execution, leading to a fallback strategy 
of making extensions to ease JIT compiler output.


yes, on x86 targets, it is a much harder sell.

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

Jim Janney schrieb:
> Back in the day Niklaus Wirth had a system that was optimised for
> running Modula-2, with its own processor and operating system written in
> Modula-2.  I don't remember now what it was called.

Do you mean?
http://en.wikipedia.org/wiki/Lilith_%28computer%29

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

On Fri, 06 Jul 2012 01:29:51 +0200, Jan Burse wrote:

> Jim Janney schrieb:
>> Back in the day Niklaus Wirth had a system that was optimised for
>> running Modula-2, with its own processor and operating system written
>> in Modula-2.  I don't remember now what it was called.
> 
> Do you mean? http://en.wikipedia.org/wiki/Lilith_%28computer%29

Well spotted.

IIRC that was roughly contemporary with the Burroughs x700 systems, which 
had an interesting take on virtualisation: its MCP OS ran each user 
program in a VM that supported the conceptual model used by its 
programming language, so a FORTRAN program ran in a word-addressed VM 
with a register set, COBOL ran in a byte-addressed VM (also with 
registers) while Algol/Pascal/C (if it had existed at the time), ran in a 
stack-based VM, all using instruction sets that suited that programming 
model. Unfortunately I never got to play with that kit, but wish I had 
known more about it because it was well ahead of its time.

The nearest I got to that, somewhat later, was a 2966 running 1900 
programs (24bit word addressed, register-based, 6 bit ISO characters) 
under George 3 simultaneously with native programs (byte-addressed, stack-
based, 8-bit EBCDIC characters) under VME/B. 

IMHO the 2966 trick of hosting a VM per OS with appropriate microcode was 
neat, but was blown away by the Burroughs trick of spinning up the 
appropriate VM for each application program and controlling the lot from 
the same OS. IBM's OS/400 could do this to run S/36 software on an AS/400 
but I don't know of anything else that comes close.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Jan Burse <janburse@fastmail.fm> writes:

> Jim Janney schrieb:
>> Back in the day Niklaus Wirth had a system that was optimised for
>> running Modula-2, with its own processor and operating system written in
>> Modula-2.  I don't remember now what it was called.
>
> Do you mean?
> http://en.wikipedia.org/wiki/Lilith_%28computer%29

That's the one, thank you.  The idea of writing an OS entirely in a
higher-level language was still pretty novel.  I think the Unix kernel
was running about 20% assembly at the time.

-- 
Jim Janney

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

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

On Thu, 5 Jul 2012 08:01:55 -0700 (PDT), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>What ever happened to those processors that were supposed to run Java natively?
>
>Did Sun or anyone else ever make those?  

For some reason the early designs had a big problem with heat. This is
very bad thing in a portable unit where low power is the main goal.
-- 
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.

Arne Vajh=F8j wrote:
> (or equivalent) is rather aggressive about JIT compiling.
>=20
> .NET CLR always does it first time I believe.

WRT Java, there are options such as "-XX:CompileThreshold=3D10000" (default=
 for -server).

That means that the HotSpot compiler sees the same code 10000 times=20
before deciding to compile it.

<http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.ht=
ml>

There's a reason performance white papers for Java discuss=20
GC and other options. They can influence performance more than=20
JIT does.

<http://www.oracle.com/technetwork/java/javase/tech/performance-jsp-141338.=
html>

Not that optimization of the JITter is a bad idea.

<http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.6>

You can see the effect of memory and other non-JIT enhancements on=20
the performance of Java 6 here:
<http://www.oracle.com/technetwork/java/6-performance-137236.html#2.3>

<http://www.oracle.com/technetwork/java/hotspotfaq-138619.html>

Perhaps the source code will help you understand:
<http://openjdk.java.net/groups/hotspot/>

--=20
Lew

On Thu, 05 Jul 2012 13:00:23 -0500, BGB <cr88192@hotmail.com> wrote,
quoted or indirectly quoted someone who said :

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

RAM cost has dropped precipitously.  However, originally it very
limit.  If you did not need a JIT you could use that RAM for the
application.
-- 
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.

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.

On Thu, 05 Jul 2012 13:02:44 -0600, Jim Janney
<jjanney@shell.xmission.com> wrote, quoted or indirectly quoted
someone who said :

>Back in the day Niklaus Wirth had a system that was optimised for
>running Modula-2, with its own processor and operating system written in
>Modula-2.  I don't remember now what it was called.
 Lilith.
see
http://www.ethistory.ethz.ch/rueckblicke/departemente/dinfk/forschung/weitere_seiten/lilith/index_EN/popupfriendly/
-- 
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.

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

On Fri, 6 Jul 2012 00:42:25 +0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote, quoted or indirectly quoted
someone who said :

>Unfortunately I never got to play with that kit, but wish I had 
>known more about it because it was well ahead of its time

I got to write code for the  Burroughs 1900, a successor. The code
density was about 10 times what I was used to. I loved the machine,
but it was not that much fun to code since everything was done at a
high level language level.   It was just so straightforward. The thing
I found most fun was NCP language.  Even a salesman could write a
custom program for polling a set of multi-drop terminals.

The underlying hardware had only 24 bits addressing, but it was bit
addressable. That let you address bytes with 21 bits, a mere 2
megabytes.Yet that little machine pumped out transactions like you
would not believe.  It used memory very cleverly dynamically balancing
system, app, database, disk cache.

I suppose they could have extended the architecture, leaving the
per-process limits in place. Univac and Burroughs merged to form
UniSys.  I don't know what happened to their various architectures.  

Univac had the 1100 36 bit machines, and some mid range IBM
compatibles inherited from RCA. Burroughs had the high end Algol
machines (fiendishly complex), mid range decimal addressed (designed
for easy assembler coding) and the 1900 series -- the interpreter per
language design.


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

Roedy Green schrieb:
> On Thu, 05 Jul 2012 13:02:44 -0600, Jim Janney
> <jjanney@shell.xmission.com> wrote, quoted or indirectly quoted
> someone who said :
>
>> Back in the day Niklaus Wirth had a system that was optimised for
>> running Modula-2, with its own processor and operating system written in
>> Modula-2.  I don't remember now what it was called.
>   Lilith.
> see
> http://www.ethistory.ethz.ch/rueckblicke/departemente/dinfk/forschung/weitere_seiten/lilith/index_EN/popupfriendly/
>

But it was not the only machine used in teaching
those days.

In the vincinity of the ETH one could find in
the mid 80's:

- CDC via Batch
- VAX via Tektronic
- Apple ][
- Lilith
- Sun 3/60
- Cray-2 via Batch
- What else?

And in personal use:

- MZ 80K
- Atari ST
- Amiga 500
- Macintosh
- What else?

The fun thing was moving code from one platform to
another. But it didn't happen that often.

Corresponding concern only arised more deeply 10
years later.

Bye

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

On Fri, 06 Jul 2012 13:53:21 -0700, Roedy Green wrote:

> The underlying hardware had only 24 bits addressing, but it was bit
> addressable. That let you address bytes with 21 bits, a mere 2
> megabytes.Yet that little machine pumped out transactions like you would
> not believe.  It used memory very cleverly dynamically balancing system,
> app, database, disk cache.
>
As I'm certain you know, driving 24x80 green screens allowed machines to 
use very much less memory than today's hardware with its memory-hungry 
high-resolution graphics. The BBC's pair of 2966s could each run 10-12 
online IDMSX-based systems, which together were accessed by 300-400 
terminals, yet each machine did all that with 16 MB of RAM.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 07/06/2012 11:04 PM, Jan Burse wrote:

> - CDC via Batch
> - VAX via Tektronic
> - Apple ][
> - Lilith
> - Sun 3/60
> - Cray-2 via Batch
> - What else?

I used to love working on a DEC-PDP11 running Unix. A great machine and 
it had a Modula 2 compiler to boot.

>
> And in personal use:
>
> - MZ 80K
> - Atari ST

That one was awesome. I still have mine collecting dust in the attic.

Back then (somewhere around 1986) I built a preemptive (timer interrupt 
based) threading library for it. It allowed any number of C functions to 
be run "in parallel" with each other and the main thread, only limited 
by the available memory to be allocated as thread stacks.

Built quite some cool games with that.


Ah, the good old days...

Silvio

On 7/6/2012 5:18 PM, Martin Gregorie wrote:
> On Fri, 06 Jul 2012 13:53:21 -0700, Roedy Green wrote:
>
>> The underlying hardware had only 24 bits addressing, but it was bit
>> addressable. That let you address bytes with 21 bits, a mere 2
>> megabytes.Yet that little machine pumped out transactions like you would
>> not believe.  It used memory very cleverly dynamically balancing system,
>> app, database, disk cache.
>>
> As I'm certain you know, driving 24x80 green screens allowed machines to
> use very much less memory than today's hardware with its memory-hungry
> high-resolution graphics. The BBC's pair of 2966s could each run 10-12
> online IDMSX-based systems, which together were accessed by 300-400
> terminals, yet each machine did all that with 16 MB of RAM.

     "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
But yew troi tellin' the kids nawadays ..."

     [*] A couple decades ago it suddenly dawned on me that my
rather bare-bones video card had sixteen times the memory of my
college's mainframe.  But yew troi tellin' the kids nawadays ...

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

On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman wrote:

> On 7/6/2012 5:18 PM, Martin Gregorie wrote:
>> On Fri, 06 Jul 2012 13:53:21 -0700, Roedy Green wrote:
>>
>>> The underlying hardware had only 24 bits addressing, but it was bit
>>> addressable. That let you address bytes with 21 bits, a mere 2
>>> megabytes.Yet that little machine pumped out transactions like you
>>> would not believe.  It used memory very cleverly dynamically balancing
>>> system,
>>> app, database, disk cache.
>>>
>> As I'm certain you know, driving 24x80 green screens allowed machines
>> to use very much less memory than today's hardware with its
>> memory-hungry high-resolution graphics. The BBC's pair of 2966s could
>> each run 10-12 online IDMSX-based systems, which together were accessed
>> by 300-400 terminals, yet each machine did all that with 16 MB of RAM.
> 
>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz. But yew
> troi tellin' the kids nawadays ..."
> 
>      [*] A couple decades ago it suddenly dawned on me that my
> rather bare-bones video card had sixteen times the memory of my
> college's mainframe.  But yew troi tellin' the kids nawadays ...

I wuz IMPRESSD by awl thet MEMORY in the 2966. 

The biggest 1900 I ever used, a 1904S, had 256 Kwords of core memory 
(24bit words). The one that taught me how to tune George 3 was a 1903S 
with 32 Kwords of core memory - the equivalent of either 96 kB (counting 
bits) or 128 KB (counting characters). The 1900 packed 4 6-bit ISO 
characters into a word. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Fri, 06 Jul 2012 13:50:17 -0700, Gene Wirchenko <genew@ocis.net>
wrote, quoted or indirectly quoted someone who said :

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

It was probably at a lecture at Java One or at the Colorado software
conference.  I got to ask Bill Joy a number of questions. It might
have been that day.
-- 
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.

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.

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

>     "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>But yew troi tellin' the kids nawadays ..."

Univac made a unit record handling computer with 16K.  Yet we had
threads in the thing and look-ahead i/o.  Someday people won't believe
this.  A beast like this ran the Vancouver Stock exchange.

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

On Sat, 07 Jul 2012 00:13:44 +0200, Silvio Bierman <silvio@moc.com>
wrote, quoted or indirectly quoted someone who said :

>I used to love working on a DEC-PDP11 running Unix. A great machine and 
>it had a Modula 2 compiler to boot.

The magic for me was the OS that did not crash several times a day. I
loved writing assembler for it.  It was so logical. I think of C as a
high level assembler for it.

One of the most fun machines was the MINC with RT-11.  It has all
kinds of real world interface i/o boards in it.  I used it to control
a complicated solar energy experiment.

Is DEC/VAX still around?
-- 
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.

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

On 7/6/2012 9:10 PM, Roedy Green wrote:
> On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>> But yew troi tellin' the kids nawadays ..."
>
> Univac made a unit record handling computer with 16K.  Yet we had
> threads in the thing and look-ahead i/o.  Someday people won't believe
> this.  A beast like this ran the Vancouver Stock exchange.
>

give it a few years and GB will likely seem small...

like, "how could you write that application using under 1GB of RAM?".

On 7/7/2012 10:42 AM, BGB wrote:
> On 7/6/2012 9:10 PM, Roedy Green wrote:
>> On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
>> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>>> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>>> But yew troi tellin' the kids nawadays ..."
>>
>> Univac made a unit record handling computer with 16K.  Yet we had
>> threads in the thing and look-ahead i/o.  Someday people won't believe
>> this.  A beast like this ran the Vancouver Stock exchange.
>>
>
> give it a few years and GB will likely seem small...
>
> like, "how could you write that application using under 1GB of RAM?".
>

     640YB ought to be enough for anybody.

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

On 7/6/2012 3:24 PM, Roedy Green wrote:
> On Thu, 05 Jul 2012 13:00:23 -0500, BGB <cr88192@hotmail.com> wrote,
> quoted or indirectly quoted someone who said :
>
>> 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.
>
> RAM cost has dropped precipitously.  However, originally it very
> limit.  If you did not need a JIT you could use that RAM for the
> application.
>

yeah, one can sometimes forget about small amounts of RAM.


a while back, I was faced with a mystery of something like "how would I 
run my VM on a target which only allows 16MB of RAM per application?".

looked at process size when firing up basic interpreter: ~ 80MB.
ended up adding a feature to down-size a lot of the hash tables, which 
shaved off a reasonable amount, and a lot was also going into the 
initial start-up heap (64MB), which was then reduced to 16MB, ...

eventually this effort died off due to a lack of relevance.


a bigger issue at the moment actually tends to be the amount of RAM 
being eaten up mostly by VM metadata (~ 100MB at present), which would 
likely require a more compact representation (at present, it is mostly 
stored as a large in-memory tree structure vaguely similar to an AVL 
tree, except with a 3-way node split).

not that it matters much on typical a desktop PC, especially as the 
world is in the transition to 64-bits anyways.

On 7/6/2012 10:10 PM, Roedy Green wrote:
> On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>> But yew troi tellin' the kids nawadays ..."
>
> Univac made a unit record handling computer with 16K.  Yet we had
> threads in the thing and look-ahead i/o.  Someday people won't believe
> this.  A beast like this ran the Vancouver Stock exchange.

     The Wikipedia article on the VSE makes interesting reading.  This
bit I found somewhat eyebrow-raising:

	The history of the exchange's index provides a standard case
	example of large errors arising from seemingly innocuous
	floating point calculations. [...] The accumulated truncations
	led to an erroneous loss of around 25 points per month."

Not enough RAM to retain the "unimportant" digits?

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

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.

On Fri, 06 Jul 2012 19:10:56 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

>On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
><esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
>someone who said :
>
>>     "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>>total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>>But yew troi tellin' the kids nawadays ..."
>
>Univac made a unit record handling computer with 16K.  Yet we had
>threads in the thing and look-ahead i/o.  Someday people won't believe
>this.  A beast like this ran the Vancouver Stock exchange.

     I think that it would be a good idea to run people through the
CARDIAC book.  Let them program something with tight memory
constraints.

Sincerely,

Gene Wirchenko

On Fri, 06 Jul 2012 13:26:58 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

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

I wonder how long until hyperjits.  They would burn a programmable
gate array to handle the innermost loops once they saw it was
justified.  It would be optimised to the gate level.
-- 
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.

On Sat, 07 Jul 2012 11:38:13 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>On 7/6/2012 10:10 PM, Roedy Green wrote:
>> On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
>> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>>> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>>> But yew troi tellin' the kids nawadays ..."
>>
>> Univac made a unit record handling computer with 16K.  Yet we had
>> threads in the thing and look-ahead i/o.  Someday people won't believe
>> this.  A beast like this ran the Vancouver Stock exchange.
>
>     The Wikipedia article on the VSE makes interesting reading.  This
>bit I found somewhat eyebrow-raising:
>
>	The history of the exchange's index provides a standard case
>	example of large errors arising from seemingly innocuous
>	floating point calculations. [...] The accumulated truncations
>	led to an erroneous loss of around 25 points per month."
>
>Not enough RAM to retain the "unimportant" digits?

     Probably not.  I would blame the use of FP.

Sincerely,

Gene Wirchenko

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.

....

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

Roedy Green wrote:
>> 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.
>
> I wonder how long until hyperjits.  They would burn a programmable
> gate array to handle the innermost loops once they saw it was
> justified.  It would be optimised to the gate level.

How would these guys "unburn" the gates - reprogram them to a different 
configuration?

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

On 2012-07-07 02:16, Roedy Green <see_website@mindprod.com.invalid> wrote:
> On Sat, 07 Jul 2012 00:13:44 +0200, Silvio Bierman <silvio@moc.com>
> wrote, quoted or indirectly quoted someone who said :
>
>>I used to love working on a DEC-PDP11 running Unix. A great machine and 
>>it had a Modula 2 compiler to boot.
[...]
> One of the most fun machines was the MINC with RT-11.
[...]
>
> Is DEC/VAX still around?

DEC replaced the VAX architecture (which was quite different from the
PDP11 architecture) with the Alpha architecture 20 years ago. DEC was
bought by Compaq a few years later which in turn was bought by HP.

There may still be VAXes running, though (I've seen one just a few years
ago).

	hp


-- 
   _  | Peter J. Holzer    | Deprecating human carelessness and
|_|_) | Sysadmin WSR       | ignorance has no successful track record.
| |   | hjp@hjp.at         | 
__/   | http://www.hjp.at/ |  -- Bill Code on asrg@irtf.org

On 2012-07-08 04:19, Gene Wirchenko <genew@ocis.net> wrote:
> On Sat, 07 Jul 2012 11:38:13 -0400, Eric Sosman
><esosman@ieee-dot-org.invalid> wrote:
>>     The Wikipedia article on the VSE makes interesting reading.  This
>>bit I found somewhat eyebrow-raising:
>>
>>	The history of the exchange's index provides a standard case
>>	example of large errors arising from seemingly innocuous
>>	floating point calculations. [...] The accumulated truncations
>>	led to an erroneous loss of around 25 points per month."
>>
>>Not enough RAM to retain the "unimportant" digits?
>
>      Probably not.  I would blame the use of FP.

Actually, it looks like they used a *fixed point* representation (3
decimal digits), not a floating point representation (although that
doesn't make much difference in this case since the magnitude stays
about the same). The obvious error is that they always truncated the
value, thus accumulating the error[1]. If they had rounded to nearest
most errors would have cancelled out. If they had used double precision
binary floating point numbers and not rounded to 3 decimal digits after
each trade the error would have been too small to notice (about 1 point
in 30 million years).

Anyway, that's a great example. I will use it in the next "binary
floating point is evil" discussion ;-).

	hp

[1] The second error was that they tried to compute the new value from
    the old value and the change at all - that's pretty much guarantueed
    to accumulate some error over time.


-- 
   _  | Peter J. Holzer    | Deprecating human carelessness and
|_|_) | Sysadmin WSR       | ignorance has no successful track record.
| |   | hjp@hjp.at         | 
__/   | http://www.hjp.at/ |  -- Bill Code on asrg@irtf.org

In article <jt5okh$53a$1@dont-email.me>, esosman@ieee-dot-org.invalid 
says...

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

Thet's a pretty single threaded point of view.

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

In fact optimiziation, profiling an compiling can be done while the code 
is being interpreted.

>      I dunno: Are JIT's nowadays smart enough to recognize code
> that will (future tense) execute too few times to be worth JITting?

As far as I know it does take things like simple loop counters into 
account when comparing invocation counts to the compilation threshold, 
so it can compile more eagerly.

Kind regards,
-Wanja-


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

On 7/8/2012 8:40 AM, Wanja Gayk wrote:
> In article <jt5okh$53a$1@dont-email.me>, esosman@ieee-dot-org.invalid
> says...
>
>>       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.
>
> Thet's a pretty single threaded point of view.
>
>> 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.
>
> In fact optimiziation, profiling an compiling can be done while the code
> is being interpreted.
>

potentially, but some profiling activities will risk reducing 
interpreter performance, since they have to be done inline with 
interpreting the code (for example, updating counters, ...).

if the program is both multi-threaded and CPU bound, then the effects of 
a JIT running in a different thread may be visible, but granted, it is 
also fairly unlikely for many apps (many are not CPU-bound, and many of 
which are CPU bound have most of their activity concentrated in 1 or 2 
threads anyways).


>>       I dunno: Are JIT's nowadays smart enough to recognize code
>> that will (future tense) execute too few times to be worth JITting?
>
> As far as I know it does take things like simple loop counters into
> account when comparing invocation counts to the compilation threshold,
> so it can compile more eagerly.
>

yep.

a simple strategy like "compile this code once it has been executed N 
times" actually works reasonably well.

code executed less than this remains interpreted, and probably isn't 
really a huge time-waster anyways, whereas code which is executed often 
will more quickly trigger the JIT to "do its thing" (causing it to go 
faster).

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

On Sat, 07 Jul 2012 23:04:37 -0700, Lew <noone@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>
>How would these guys "unburn" the gates - reprogram them to a different 
>configuration?

they would not.  Presumably these things would be so cheap that you
would just replace a bank that had too many pieces of abandoned code,
and repack them onto a fresh bank, like the way the Replicator repacks
zips when they get too full of junk.  If there were sufficiently
dense, e.g. some sort of 3D array, you might just keep everything.

Also somebody might invent an erasable array, where you don't
literally burn, just program.

I hope somebody does this in the lab no matter how impractical just to
find out the order of magnitude efficiency improvement that could be
had.
-- 
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.

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       |

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

Roedy Green wrote:
> Lew wrote, quoted or indirectly quoted someone who said :
>> How would these guys "unburn" the gates - reprogram them to a different
>> configuration?
>
> they would not.  Presumably these things would be so cheap that you
> would just replace a bank that had too many pieces of abandoned code,
> and repack them onto a fresh bank, like the way the Replicator repacks
> zips when they get too full of junk.  If there were sufficiently
> dense, e.g. some sort of 3D array, you might just keep everything.
>
> Also somebody might invent an erasable array, where you don't
> literally burn, just program.
>
> I hope somebody does this in the lab no matter how impractical just to
> find out the order of magnitude efficiency improvement that could be
> had.

The reason I ask is that the HotSpot compiler works by compiling and 
uncompiling sections of code many times as program dynamics dictate.

Write-once mechanisms will need huge capacity to handle the myriads of 
abandoned code fragments. Also, the compilation is occurring during program 
execution, so they'd also have to be write-extremely-fucking-fast, or WEFF.

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

On Sun, 08 Jul 2012 11:52:52 -0700, 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.
  
> 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.
    
> 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 
recompilation vs the initial JIT pass? If its quite infrequent, then 
temporary reversion to bytecode may be a worthwhile strategy, especially 
if the recompilation isn't restricted to exactly the same set of bytecode 
instructions.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

On Fri, 06 Jul 2012 19:03:30 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>It was probably at a lecture at Java One or at the Colorado software
>conference.  I got to ask Bill Joy a number of questions. It might
>have been that day.

http://www.oracle.com/technetwork/java/whitepaper-135217.html#3
says the optimisations done include:

Deep inlining and inlining of potentially virtual calls: as described
above, method inlining combined with global analysis and dynamic
deoptimization are used by both the client and server compilers to
enable deep inlining and therefore elimination of a substantial amount
of method call overhead. 

Fast instanceof/checkcast: the Java HotSpot VM and compilers support a
novel technique for accelerating the dynamic type tests frequently
required by the Java programming language for type safety. This
further decreases the run-time cost of programming in object-oriented
style. 

Range check elimination: The Java programming language specification
requires array bounds checking to be performed with each array access.
An index bounds check can be eliminated when the compiler can prove
that an index used for an array access is within bounds. 

Loop unrolling: the Server VM features loop unrolling, a standard
compiler optimization that enables faster loop execution. Loop
unrolling increases the loop body size while simultaneously decreasing
the number of iterations. Loop unrolling also increases the
effectiveness of other optimizations. 

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

On 07/07/2012 04:07, Roedy Green allegedly 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.

Sounds to me like you could be misinterpreting that, Roedy. It says
"method... running in a loop". Not: loop running in a method. I'd rather
interpret that as being about a method running repeatedly in a loop.

Agree with the "walk on water" thing, though.

-- 
DF.

Daniele Futtorovic wrote:
> Roedy Green allegedly wrote:
> Lew 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.
> 
> Sounds to me like you could be misinterpreting that, Roedy. It says
> "method... running in a loop". Not: loop running in a method. I'd rather
> interpret that as being about a method running repeatedly in a loop.
> 
> Agree with the "walk on water" thing, though.

As cited upthread:
<http://www.oracle.com/technetwork/java/whitepaper-135217.html#optimizations>

Loop unrolling is one of the optimizations mentioned.

-- 
Lew

On Tue, 10 Jul 2012 01:13:06 +0200, Daniele Futtorovic
<da.futt.news@laposte-dot-net.invalid> wrote, quoted or indirectly
quoted someone who said :

>Sounds to me like you could be misinterpreting that, Roedy. It says
>"method... running in a loop". Not: loop running in a method. I'd rather

That would be much simpler. That way you would never optimise a loop
in the process of being executed.  That sounds like a much more
plausible task.  All you have to do is get the stack right and leave
all the class and instance variable where they are.
 
The problem it is could wait quite a long time to interrupt. I wonder
how it actually works. 
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Mathematicians and computer scientists are far more interested 
in impressing you than informing you. If this were not
so, the tutorials on building a robots.txt file, for example,
would consist primarily of an annotated example. What you get 
instead are nothing but inscrutable adstract fragments in some 
obscure dialect of BNF.

On 12/07/2012 00:41, Roedy Green allegedly wrote:
> On Tue, 10 Jul 2012 01:13:06 +0200, Daniele Futtorovic
> <da.futt.news@laposte-dot-net.invalid> wrote, quoted or indirectly
> quoted someone who said :
> 
>> Sounds to me like you could be misinterpreting that, Roedy. It says
>> "method... running in a loop". Not: loop running in a method. I'd rather
> 
> That would be much simpler. That way you would never optimise a loop
> in the process of being executed.  That sounds like a much more
> plausible task.  All you have to do is get the stack right and leave
> all the class and instance variable where they are.
>  
> The problem it is could wait quite a long time to interrupt. I wonder
> how it actually works. 

Well, look at it like this: the longer (and hence less frequently) the
method runs (it running indefinitely being the extreme case), the less
reason there is to replace it.

-- 
DF.

On 08/07/2012 8:56 PM, Lew wrote:
> 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.

It has been a long time since I worked on optimizing compiler 
technology, but my fragmented memories suggest that it's not "all or 
nothing" with regard to what information you need for optimization. Some 
intra-procedural data flow analysis remains valid even if 
inter-procedural or inter-class information changes, and some 
optimization only depend on local information.

On Monday, July 16, 2012 10:22:21 AM UTC-7, David Lamb wrote:
> On 08/07/2012 8:56 PM, Lew wrote:
> > 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.
> 
> It has been a long time since I worked on optimizing compiler 
> technology, but my fragmented memories suggest that it's not "all or 
> nothing" with regard to what information you need for optimization. Some 
> intra-procedural data flow analysis remains valid even if 
> inter-procedural or inter-class information changes, and some 
> optimization only depend on local information.

I said "compilations". You said "optimizations".

Apples. Oranges.

-- 
Lew

In article <jtfokt$iae$1@dont-email.me>, da.futt.news@laposte-dot-
net.invalid says...

> Sounds to me like you could be misinterpreting that, Roedy. It says
> "method... running in a loop". Not: loop running in a method.

Which loop is not running in a method?

Kind regards,
Wanja

-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 7/21/2012 12:46 PM, Wanja Gayk wrote:
> In article <jtfokt$iae$1@dont-email.me>, da.futt.news@laposte-dot-
> net.invalid says...
>
>> Sounds to me like you could be misinterpreting that, Roedy. It says
>> "method... running in a loop". Not: loop running in a method.
>
> Which loop is not running in a method?

	class Clown {
	    static {
	        while(true) System.out.println("This one.");
	    }
	}

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

In article <juenhg$3jn$1@dont-email.me>, esosman@ieee-dot-org.invalid 
says...

> >> Sounds to me like you could be misinterpreting that, Roedy. It says
> >> "method... running in a loop". Not: loop running in a method.
> >
> > Which loop is not running in a method?
> 
> 	class Clown {
> 	    static {
> 	        while(true) System.out.println("This one.");
> 	    }
> 	}

Which, from a VM point of view, is nothing else than an anonymous static 
initializer method.

Kind regards,
Wanja


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 7/21/2012 1:23 PM, Wanja Gayk wrote:
> In article <juenhg$3jn$1@dont-email.me>, esosman@ieee-dot-org.invalid
> says...
>
>>>> Sounds to me like you could be misinterpreting that, Roedy. It says
>>>> "method... running in a loop". Not: loop running in a method.
>>>
>>> Which loop is not running in a method?
>>
>> 	class Clown {
>> 	    static {
>> 	        while(true) System.out.println("This one.");
>> 	    }
>> 	}
>
> Which, from a VM point of view, is nothing else than an anonymous static
> initializer method.

     I hadn't thought it necessary to be so explicit, but okay:

	class Clown {
	    static {
	        while(true) System.out.println(":)");
	    }
	}

(Sigh.)

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

On 21/07/2012 18:46, Wanja Gayk allegedly wrote:
> In article <jtfokt$iae$1@dont-email.me>, da.futt.news@laposte-dot-
> net.invalid says...
> 
>> Sounds to me like you could be misinterpreting that, Roedy. It says
>> "method... running in a loop". Not: loop running in a method.
> 
> Which loop is not running in a method?

Here's one: <http://physics.gu.se/LISEBERG/tf/loop.jpg>

-- 
DF.

In article <juerbe$qpi$1@dont-email.me>, esosman@ieee-dot-org.invalid 
says...

> > Which, from a VM point of view, is nothing else than an anonymous static
> > initializer method.
> 
>      I hadn't thought it necessary to be so explicit, but okay:
> 
> 	class Clown {
> 	    static {
> 	        while(true) System.out.println(":)");
> 	    }
> 	}
> 
> (Sigh.)

throw new JokeDetectorTemporallyUnavailableException("Brain on 
standby.");

Kind regards,
Wanja

-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 7/22/2012 7:17 PM, Wanja Gayk wrote:
> In article <juerbe$qpi$1@dont-email.me>, esosman@ieee-dot-org.invalid
> says...
>
>>> Which, from a VM point of view, is nothing else than an anonymous static
>>> initializer method.
>>
>>       I hadn't thought it necessary to be so explicit, but okay:
>>
>> 	class Clown {
>> 	    static {
>> 	        while(true) System.out.println(":)");
>> 	    }
>> 	}
>>
>> (Sigh.)
>
> throw new JokeDetectorTemporallyUnavailableException("Brain on
> standby.");

     In fairness, I suppose the expression "class clown" may be
an Americanism, a slang usage not covered in textbooks that even
the most assiduous and capable student might read. We all reveal
our insularities in a multitude of ways, and perhaps even more
obviously when we're trying to be "funny."  Sorry for any offense.

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