Advantages of 64-bit JVM

N

noone

Now that you can get a 65-bit JVM with J2SDK 1.4.2 for Solaris SPARC (
or for Intel Itanium ), what advantages does a 64-bit JVM have ?

The only thing that I can see is accessing more memory.

Given that, my eight SPARC boxes running Solaris 8 does not have more
than 4 GB of RAM.

Will there be performance improvement since ( like in the days of
Windows from 16-bit to 32-bit ), there would no more "switching" from
32-bit to 64-bit tasks / threads / watch-a-ma-callit ?
 
S

Stephan Eggermont

noone said:
Now that you can get a 65-bit JVM with J2SDK 1.4.2 for Solaris SPARC (
or for Intel Itanium ), what advantages does a 64-bit JVM have ?

The only thing that I can see is accessing more memory.

Yes. It allows for the implementation of datawarehouses.
For the price of an EMC disk array you can now create a terabyte
ram pc grid.

Stephan
 
T

Tim Tyler

noone said:
Now that you can get a 65-bit JVM with J2SDK 1.4.2 for Solaris SPARC
(or for Intel Itanium ), what advantages does a 64-bit JVM have ?

The only thing that I can see is accessing more memory.

Bigger chips have more scope for on-chip parallelism - which can lead
to improvements in performance over a single smaller chip.
 
R

Roedy Green

Now that you can get a 65-bit JVM with J2SDK 1.4.2 for Solaris SPARC (
or for Intel Itanium ), what advantages does a 64-bit JVM have ?

The only thing that I can see is accessing more memory.

the other advantage is that in runs on the expensive 64 bit machines
in native mode, so should likely be faster than using them in some
32-bit emulation.

The advantage of 64 bit addresses is they let you address all the RAM
you can afford. The disadvantage is they waste ram if you have small
problem.
 
D

Dimitri Maziuk

Roedy Green sez:
the other advantage is that in runs on the expensive 64 bit machines
in native mode, so should likely be faster than using them in some
32-bit emulation.

In theory. In practice 64-bit SPARCs run 32-bit code natively.
64-bit binary may run faster than 32-bit version, depending on
compiler, what app. it is, and so on, or it may not. Sun's JVM
does not seem to run any faster in 64-bit mode. (In our tests
Sun's JVM on 2 300MHz CPU SPARC box runs about 4 times slower
than it does on 1 1.2GHz Intel CPU.)
The advantage of 64 bit addresses is they let you address all the RAM
you can afford.

(Provided you can afford more RAM than 32-bit address space
supports.)

Given the above it's a moot point in practice: by the time you've
created enough objects to fill up 32-bit address space, your JVM
has probably slowed down to the point of being unusable anyway.

Dima
 
R

Roedy Green

Given the above it's a moot point in practice: by the time you've
created enough objects to fill up 32-bit address space, your JVM
has probably slowed down to the point of being unusable anyway.

Dima

My organic chem lab prof chastising us for wasting expensive solvents
for test tube cleaning would tell us that when we became researchers,
THEN we would have so much money for research grants we could wash our
feet in acetone.

In a similar way, when you have more than 4 gigs of RAM you can afford
to wash your feet in it, and use it in ways we mortals would not
imagine. It becomes more like a fast hard disk to store a complete
database. Much of it may not be accessed for weeks at a time other
than for backup.
 
D

Dimitri Maziuk

Roedy Green sez:
My organic chem lab prof chastising us for wasting expensive solvents
for test tube cleaning would tell us that when we became researchers,
THEN we would have so much money for research grants we could wash our
feet in acetone.

In a similar way, when you have more than 4 gigs of RAM you can afford
to wash your feet in it, and use it in ways we mortals would not
imagine. It becomes more like a fast hard disk to store a complete
database. Much of it may not be accessed for weeks at a time other
than for backup.

But that's the point: it'll *take* weeks to find the objects you
want in > 4GB heap of 'em.

Some apps may need to store > 4GB of, say, ints and process them
one at a time. Then you (impersonal "you", of course) could do a
binary search on sorted list and that will be fast -- for values
of "fast" in O(log(1073741827)).

In general case you'll be storing compound objects with multiple
attributes and looking for a subset of > 4GB based on some
combination of some of the attributes. When you think of
implementation of searches, sure, you can do it to satisfy your
scientific curiosity -- if you have enough money in research
grants, that is. IRL you'll just dump the data into a database
and use (Structured) Query Language to get to it.

Plus, if you have that much data and your app runs for weeks,
you'll probably hate losing it all when the janitor unplugs
your server to plug in vacuum cleaner. So you'll want
persistence and probably some form of logging/transactions.
You'll have to implement that, too -- or let SQl engine worry
about it.

The end result is that by the time you finished debugging all
that code your potential customers have been using an SQL-based
solution from competing vendor for years. And they won't switch
to your app even though it may be faser. Beacuse SQL-based
solution is smaller and easier to maintain, meaning: cheaper,
more robust, easily extensible. (And it probably scales better,
too, how about multi-terababyte databases?)

Dima
 
M

Mark Thornton

Dimitri said:
Roedy Green sez:



(Provided you can afford more RAM than 32-bit address space
supports.)

Given the above it's a moot point in practice: by the time you've
created enough objects to fill up 32-bit address space, your JVM
has probably slowed down to the point of being unusable anyway.

In practice the problems caused by a 32 bit address space arise much
sooner than might be expected. On Windows applications are usually
restricted to the lower 2GB of the address space and can't actually use
all of that. So with around 1.4GB of data I am already in trouble. One
or 2GB of memory is readily affordable. In fact I haven't finished
loading my data because I had to rewrite some of my code to get round
the problems caused by the lack of address space. To compound matters,
the Windows JVM require you to specify the maximum heap size in advance
(and then reserve this much of the address space). If in addition you
have significant amounts data outside the JVM heap, you have yet more
address space fragmentation.

Mark Thornton
 
M

Mladen Adamovic

Dimitri Maziuk said:
Given the above it's a moot point in practice: by the time you've
created enough objects to fill up 32-bit address space, your JVM
has probably slowed down to the point of being unusable anyway.

Do you think about possibility to have more than one JVM in memory, i.e. on
multiproccessor machine each proccessor to have its own JVM.... Don't ask me
who will use that or why to use that - it just apirienced in my head...
 
R

Roedy Green

But that's the point: it'll *take* weeks to find the objects you
want in > 4GB heap of 'em.

What? You can find them with a giant Hashtable in just one or two
hops, same as with 32 bit addressing. Unfortunately you don't have 64
bit addressing of arrays for direct lookup. You have to fake giant
arrays with arrays of arrays.

You won't use linear searching. Even then you can could search
linearly through ram perhaps 30 times faster than you could do say a
virus scan of your hard disk. I would not be weeks.
 
R

Roedy Green

Do you think about possibility to have more than one JVM in memory, i.e. on
multiproccessor machine each proccessor to have its own JVM.... Don't ask me
who will use that or why to use that - it just apirienced in my head...

You can have multiple JVMs, but of course that will waste RAM unless
the JVM designer has cleverly arranged for the read-only parts to be
in shared ram.

Of course you still have two copies of every static variable if you
have two JVMs. This may be a good thing since it may reduce
synchronized contention. (Imagine a class whose job it was simply to
issue unique ids).

OS's don't by default assign tasks to cpus. They all work off a common
queue. Whichever cpu is free takes the next task off the top of the
queue. This means many different cpus will work on a task over its
lifetime.
 
D

Dimitri Maziuk

Mladen Adamovic sez:
Do you think about possibility to have more than one JVM in memory, i.e. on
multiproccessor machine each proccessor to have its own JVM.... Don't ask me
who will use that or why to use that - it just apirienced in my head...

Last I checked 64-bit JVM was available for SPARC hardware only.
Given the price of Sun's hardware and the speed of their JVM on
it compared to IA-32, you're better off buying two wintel boxes
and running each of your two JVMs on its own computer.

Multiple CPUs can come in handy with JVMs new ability to run GC
in a separate thread. However, CPU scheduling is done by the OS,
so you have little control over where and how GC is run.

Ideally you'd want an OS that lets you lock two or more CPUs for
exclusive use by JVM (and of course you'll need another CPU or
two to run everything else.)

Dima
 
M

Mark Thornton

Dimitri said:
Mladen Adamovic sez:



Last I checked 64-bit JVM was available for SPARC hardware only.
Given the price of Sun's hardware and the speed of their JVM on
it compared to IA-32, you're better off buying two wintel boxes
and running each of your two JVMs on its own computer.

You haven't checked for a while --- a 64 bit JVM has been available for
Itanium for some time. I believe there has also been one for Alpha for
even longer (not from Sun). A 64 bit JVM for the AMD64 is expected in
the first half of next year.

Mark Thornton
 

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

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top