Java processors

J

Jan Burse

Roedy said:

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
 
L

Lew

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

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

Martin Gregorie

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

Silvio Bierman

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

Eric Sosman

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

Martin Gregorie

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

Roedy Green

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

Roedy Green


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

Roedy Green

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

Roedy Green

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

BGB

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

BGB

"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?".
 
E

Eric Sosman

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

BGB

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

Eric Sosman

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

Roedy Green

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

Gene Wirchenko

"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
 
R

Roedy Green

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

Gene Wirchenko

"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
 
B

BGB

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.

....
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top