64 bit linux on VM to run Java app

java-programmer, 64 bit linux on VM to run Java app On Fri, 20 Jun 2008 15:58:35 GMT, Roedy Green
<email***@***.com> wrote, quoted or indirectly quoted
someone who said :

>
>see http://mindprod.com/bgloss/sixtyfourbit.html

Thanks for all your input in whipping that entry into shape.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

java-programmer >> 64 bit linux on VM to run Java app On Fri, 20 Jun 2008 15:58:35 GMT, Roedy Green
<email***@***.com> wrote, quoted or indirectly quoted
someone who said :

>
>see http://mindprod.com/bgloss/sixtyfourbit.html

Thanks for all your input in whipping that entry into shape.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

java-programmer >> 64 bit linux on VM to run Java app On Wed, 25 Jun 2008, Roedy Green wrote:

> Seems to me some years ago I read about a 32-bit machine with an
> astounding (at least astounding at the time) number of registers
> organised as a sliding register window. This strikes me as the best way
> to handle things to avoid spending most of your life saving/restoring
> registers.

SPARC does this, i believe. It does seem like a very good idea. I think it
deals with running out of registers by raising an interrupt, and then
there are kernel-mode instructions which let the handler spill registers
to memory, and load them back later. All very clever.

tom

--
shouting drunkenly about 6502 assembler at parties

java-programmer >> 64 bit linux on VM to run Java app On Wed, 25 Jun 2008, Roedy Green wrote:

> On Tue, 24 Jun 2008 18:52:57 +0100, Tom Anderson
> <email***@***.com> wrote, quoted or indirectly quoted someone who
> said :
>
>> But this doesn't just affect the amount of memory a structure uses
>
> A Java object consists mostly of references to other objects, usually
> Strings. Each of these is twice the size.
>
> Even the ints could well be twice as fat. Often placing ints on an
> even 64 bit boundary will speed access. So depending on how your run
> time works, many of your ints could have 32 bits of padding too.
>
> I don't know if the stacks go 64 bit internally. If so, they too would
> be twice as fat.
>
> The machine code itself is would be fluffier too. 8-bit later 16- bit
> and 32 bit code was designed for compactness as the expense of
> orthogonality.

Hmm. Not sure that's true. The PDP-11 instruction set is often held up as
a model of orthogonality, and that's 16-bit.

You're probably right about code getting bigger, though. That seems to be
a trend.

> The extra registers in 64 bit will chew up more selector space in the
> instructions.

Only a bit or two. That's the power of the exponential function!

Anyway, i don't know if these remarks were aimed at me - i was *agreeing*
that 64-bit uses more memory.

tom

--
shouting drunkenly about 6502 assembler at parties

java-programmer >> 64 bit linux on VM to run Java app On Wed, 25 Jun 2008, Roedy Green wrote:

> On Tue, 24 Jun 2008 18:52:57 +0100, Tom Anderson
> <email***@***.com> wrote, quoted or indirectly quoted someone who
> said :
>
>> If you're walking a linked list, for instance, then you need to load
>> one pointer per link; with an 8 GB/s memory interface, that's 2 billion
>> links per second on a 32-bit machine, but only 1 billion on a 64-bit
>
> would not the memory fetch bus typically twice as wide on 64 bit, thus
> giving you the name effective throughput in links per second?

No. Bus width is not coupled to register width these days. I'm not sure if
there is an architectural limit to bus width - the latest graphics
chipsets have 512-bit buses connecting the GPU to the card's RAM. Thinking
about it, the width should be limited to the width of a cache line, since
that's the unit you do memory reads in. Although i suppose you could
always transfer multiple lines at once.

tom

--
shouting drunkenly about 6502 assembler at parties

java-programmer >> 64 bit linux on VM to run Java app Tom Anderson wrote:
> On Wed, 25 Jun 2008, Roedy Green wrote:
>
>> Seems to me some years ago I read about a 32-bit machine with an
>> astounding (at least astounding at the time) number of registers
>> organised as a sliding register window. This strikes me as the best
>> way to handle things to avoid spending most of your life
>> saving/restoring registers.
>
> SPARC does this, i believe. It does seem like a very good idea. I think
> it deals with running out of registers by raising an interrupt, and then
> there are kernel-mode instructions which let the handler spill registers
> to memory, and load them back later. All very clever.

I've done performance work both with SPARC, and before that with some
Celerity systems that did something similar.

It has its good points, but also presents problems.

First, there is the physical problem of getting fast enough transfers
between the registers and the ALU. Generally, the bigger a memory the
slower transfers between the memory and a given place in the processor.
There is a lot to be said for making the register structure very small,
very fast, and very close to the ALU.

Second, consider what happens on register stack overflow/underflow,
especially with modern coding styles that tend to have many small
functions. By the time a register window needs to be saved or restored,
the system has no data about which registers are really in use, and
which contain junk. The result is that the whole block needs to be
transfered.

I used to hate the Ackermann function, because the code to evaluate it,
which appears in a lot of benchmarks, requires large, rapid changes in
call stack depth.

Patricia

java-programmer >> 64 bit linux on VM to run Java app Tom Anderson wrote:
> On Wed, 25 Jun 2008, Roedy Green wrote:
>> Seems to me some years ago I read about a 32-bit machine with an
>> astounding (at least astounding at the time) number of registers
>> organised as a sliding register window. This strikes me as the best
>> way to handle things to avoid spending most of your life
>> saving/restoring registers.
>
> SPARC does this, i believe. It does seem like a very good idea. I think
> it deals with running out of registers by raising an interrupt, and then
> there are kernel-mode instructions which let the handler spill registers
> to memory, and load them back later. All very clever.

It sounds as a great idea.

But I doubt that it is in practice.

HW at that level is beyond me, but I draw my conclusions from
the fact that newer RISC architectures (PPC, Alpha and Itanium)
does not use register windowing (Itanium uses register windowing
which has the same idea though).

Arne

java-programmer >> 64 bit linux on VM to run Java app Roedy Green wrote:
> On Tue, 24 Jun 2008 22:22:24 -0400, Arne Vajh鴍 <email***@***.com>
> wrote, quoted or indirectly quoted someone who said :
>> The compiler (JIT if Java) can only use the architectural registers. And
>> the CPU can only map architectural registers to physical registers - it
>> can not memory addresses to physical registers.
>
> You meant to say "It can not MAP memory addresses to physical
> registers" right?

Yup.

Arne

java-programmer >> 64 bit linux on VM to run Java app This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

On Wed, 25 Jun 2008, Arne Vajh鴍 wrote:

> Tom Anderson wrote:
>> On Wed, 25 Jun 2008, Roedy Green wrote:
>>> Seems to me some years ago I read about a 32-bit machine with an
>>> astounding (at least astounding at the time) number of registers organised
>>> as a sliding register window. This strikes me as the best way to handle
>>> things to avoid spending most of your life saving/restoring registers.
>>
>> SPARC does this, i believe. It does seem like a very good idea. I think it
>> deals with running out of registers by raising an interrupt, and then there
>> are kernel-mode instructions which let the handler spill registers to
>> memory, and load them back later. All very clever.
>
> It sounds as a great idea.
>
> But I doubt that it is in practice.
>
> HW at that level is beyond me, but I draw my conclusions from the fact
> that newer RISC architectures (PPC, Alpha and Itanium) does not use
> register windowing (Itanium uses register windowing which has the same
> idea though).

I wonder if it's because more modern architectures do register renaming,
which means they don't need windowing. Both are effectively ways of using
more physical registers than you have architectural registers, so having
both is redundant; windowing takes less logic, but renaming gives you more
performance, so as processors have got bigger, there's been a shift from
windowing to renaming. Pure speculation, of course.

tom

--
Hesgadin. It was in two parts - both of them silent. I remember this map
came with a letter accusing me of stealing eggs. I had never understood
the relationship of the map to the accusation. I still don't, but I'm
grateful for the map.