64 bit linux on VM to run Java app

stan@worldbadminton.com wrote:
> In comp.os.linux.misc General Schvantzkopf <schvantzkopf@yahoo.com> wrote:
>> 64bit capable machine. Windows user are in a different boat, they either
>> have to use the execrable Vista or live with the 3.6G memory limit in
>> XP. However the OP was asking about Virtual machines so he will be using
>
> Huh? Have been using 64-bit XP for a long time now- no mem limit I am aware of.

They were referring to the memory limit of 32-bit XP.

--
Lew

On Jun 19, 3:50*pm, "soup_or_po...@yahoo.com"
<soup_or_po...@yahoo.com> wrote:
> Can we install a VM to support 6 GB memory on a 32-bit machine?
> Basically we want to install 3 VM's running linux sharing the 6 GM
> memory. At the first glance it seems not possible. Do we need a 64-bit
> processor with 64 bit linux (Red Hat Mandriva, Fedora, etc.). Also
> since we will be running Java on the VM's do we need 64-bit Java
> compiler as well?
>
> Thanks for your help

32-bit Linux can support more than 4GB of memory if you use the
correct options when build the kernel.
The 'server' build of most distributions usually support this option.
You will then be able to run 3 JVM instances each using 2GB.

On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>64 bit means 64 bit virtual addresses not 64 bit integers.

64-bit registers, 64-bit addresses and 64-bit operands usually all go
together. Can you think of any exceptions?


--

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

On Mon, 23 Jun 2008, Roedy Green wrote:

> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> 64 bit means 64 bit virtual addresses not 64 bit integers.
>
> 64-bit registers, 64-bit addresses and 64-bit operands usually all go
> together. Can you think of any exceptions?

The Atari Jaguar. 64-bit registers, 24-bit addresses and 32-bit operands!

Well, sort of. The CPU was a Motorola 68000, which is a 32-bit chip with
24 address pins and an instruction set that's still slanted towards 16-bit
operations. The graphics, memory control and sound chips were clean
32-bit. The data bus was 64-bit. The interesting bit was the blitter and
'object processor', both of which were somewhat specialised chips designed
for shunting data around and doing repetitive operations of limited
complexity to it - but doing them incredibly fast. They were 64-bit.

You might say that since the 68k CPU was 32-bit, the machine was 32-bit,
but the idea was that the 68k was just there to boot the system,
initialise the other chips, manage controller input, etc, and that the
real heart of the system was the custom chipset, which would execute all
the real logic - the 68k was a sort of management chip, not a CPU.
However, according to my very superficial understanding of the Jaguar's
history, game programmers did use the 68k for game logic, and used the
custom chips purely for graphics.

In any case, the only other chip which could really have been considered
the primary element was the GPU, which was a general-purpose RISC chip
with some graphics-specific extensions, but that was only 32 bit anyway.
So, it was more of a 32-bit machine with a 64-bit bus and some 64-bit
graphics chips.

If i can change the numbers a bit, all the 8-bit processors had 16-bit
address spaces. Some 16-bit machines had >16-bit address spaces too, like
all that segment register madness on the early x86 chips.

tom

--
I hate to advocate drugs, alcohol, violence, or insanity to anyone,
but they've always worked for me. -- Hunter S. Thompson

On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>I assume you are trying to tell that the virtual address space
>is 9 million GB. Which is wrong. The potential max of virtual
>address space is 16 EB (16 billion GB)

Often you can't always use all 64 bits for addressing, but if you
did, that would give you addresses 0 .. 2^64-1
i..e 0.. 18,446,744,073,709,551,615

We have the problem of binary and decimal gigabytes. The article
http://mindprod.com/ggloss/sixtyfourbit.html is in the Buyer's
Glossary, not the Java glossary, so it is not aimed at programmers. I
thought it thus best to stick to decimal. It does not really matter.
The point I am trying to make is the addressing limit is well beyond
what you could afford in real ram.

A decimal gigabyte is 10^9, so that would make it the addressability
18,446,744 gb (twice the 9 million gb I used presuming the sign bit
bit of addressing would be chewed up by housekeeping.)

How did you get your number 16 billion GB. ? three orders of magnitude
bigger?

I presume the 16-18 difference comes from you using binary gigabytes.

To sort out the confusion, NIST has devised new prefixes when you mean
binary.
see http://physics.nist.gov/cuu/Units/binary.html
--

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

Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> 64 bit means 64 bit virtual addresses not 64 bit integers.
>
> 64-bit registers, 64-bit addresses and 64-bit operands usually all go
> together. Can you think of any exceptions?

Yes.

The VAX instruction set supports 64 bit operands in ASHQ, CLRQ, EDIV,
EMUL and MOVQ instructions.

x86 has the CDQ instruction that has a 64 bit operand.

The original CDC Cyber used 18 bit addresses (word not byte), but
had 60 bit registers for arithmetic.

If we go really way back then IBM, DEC, Univac and GE all made
computers with 36 bit registers and 18 bit addresses (word again).


Arne

Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> I assume you are trying to tell that the virtual address space
>> is 9 million GB. Which is wrong. The potential max of virtual
>> address space is 16 EB (16 billion GB)
>
> Often you can't always use all 64 bits for addressing, but if you
> did, that would give you addresses 0 .. 2^64-1
> i..e 0.. 18,446,744,073,709,551,615
>
> We have the problem of binary and decimal gigabytes. The article
> http://mindprod.com/ggloss/sixtyfourbit.html is in the Buyer's
> Glossary, not the Java glossary, so it is not aimed at programmers. I
> thought it thus best to stick to decimal. It does not really matter.
> The point I am trying to make is the addressing limit is well beyond
> what you could afford in real ram.
>
> A decimal gigabyte is 10^9, so that would make it the addressability
> 18,446,744 gb (twice the 9 million gb I used presuming the sign bit
> bit of addressing would be chewed up by housekeeping.)
>
> How did you get your number 16 billion GB. ? three orders of magnitude
> bigger?
>
> I presume the 16-18 difference comes from you using binary gigabytes.
>
> To sort out the confusion, NIST has devised new prefixes when you mean
> binary.
> see http://physics.nist.gov/cuu/Units/binary.html

The post you replied to contained the following (that you did not
quote):

#[I am ignoring the 1024 versus 1000 issue]

Is that statement unclear ????

Arne

Tom Anderson wrote:
> On Mon, 23 Jun 2008, Roedy Green wrote:
>
>> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> 64 bit means 64 bit virtual addresses not 64 bit integers.
>>
>> 64-bit registers, 64-bit addresses and 64-bit operands usually all go
>> together. Can you think of any exceptions?
>
> The Atari Jaguar. 64-bit registers, 24-bit addresses and 32-bit operands!

I think Roedy was asking for extant, relevant examples.

--
Lew

Roedy Green wrote:
> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> I assume you are trying to tell that the virtual address space
>> is 9 million GB. Which is wrong. The potential max of virtual
>> address space is 16 EB (16 billion GB)
>
> Often you can't always use all 64 bits for addressing, but if you
> did, that would give you addresses 0 .. 2^64-1
> i..e 0.. 18,446,744,073,709,551,615

Didn't check this exactly, but it looks reasonable. If we estimate
2^10 as 1000 decimal then 2^60 becomes 1000^6 or 10^18. And 2^64
will then be 16 * 10^18.

[ snip ]

> A decimal gigabyte is 10^9, so that would make it the addressability
> 18,446,744 gb (twice the 9 million gb I used presuming the sign bit
> bit of addressing would be chewed up by housekeeping.)

(18 * 10^18) / (10^9) = 18 * 10^9.
If you just strip the last _nine_ digits of 18,446,744,073,709,551,615
-like you suggest to be doing above- you'll get 18,446,744,073 gb.

> How did you get your number 16 billion GB. ? three orders of magnitude
> bigger?

Just by counting the digits I suppose.


Regards,

Kees.

--
Kees Theunissen.

Arne Vajhøj wrote:
> Roedy Green wrote:
>> On Fri, 20 Jun 2008 20:43:34 -0400, Arne Vajhøj <arne@vajhoej.dk>
>> wrote, quoted or indirectly quoted someone who said :
>>> I assume you are trying to tell that the virtual address space
>>> is 9 million GB. Which is wrong. The potential max of virtual
>>> address space is 16 EB (16 billion GB)
>>
>> Often you can't always use all 64 bits for addressing, but if you
>> did, that would give you addresses 0 .. 2^64-1
>> i..e 0.. 18,446,744,073,709,551,615
>>
>> We have the problem of binary and decimal gigabytes. The article
>> http://mindprod.com/ggloss/sixtyfourbit.html is in the Buyer's
>> Glossary, not the Java glossary, so it is not aimed at programmers. I
>> thought it thus best to stick to decimal. It does not really matter.
>> The point I am trying to make is the addressing limit is well beyond
>> what you could afford in real ram.
>>
>> A decimal gigabyte is 10^9, so that would make it the addressability
>> 18,446,744 gb (twice the 9 million gb I used presuming the sign bit
>> bit of addressing would be chewed up by housekeeping.)
>>
>> How did you get your number 16 billion GB. ? three orders of magnitude
>> bigger?
>>
>> I presume the 16-18 difference comes from you using binary gigabytes.
>>
>> To sort out the confusion, NIST has devised new prefixes when you mean
>> binary.
>> see http://physics.nist.gov/cuu/Units/binary.html
>
> The post you replied to contained the following (that you did not
> quote):
>
> #[I am ignoring the 1024 versus 1000 issue]
>
> Is that statement unclear ????

Oh and:

18,446,744,073,709,551,616 / 10^9 is *not* 18,446,744 !

It *is* billion not million !!

Arne