difference between client, server, classic and hotspot jvms

[Naresh Agarwal]

Hi

What are the different kinds of JVMs exist and in what respect do they differ.

What is the difference between client, server, classic and hotspot jvms?

thanks,
Naresh

 

[Roedy Green]

What is the difference between client, server, classic and hotspot jvms?

A client JVM would be optimised for fast starting.

A server JVW might take a while to get started, but eventually runs
faster.

A classic JVM interprets, byte code by byte code.

A hotspot JVM translates entire classes to machine code at a time.

 

[Chris Uppal]

What is the difference between client, server, classic and hotspot jvms?

IIRC, the names "classic" and "hotspot" were introduced (in 1.3??) when the
Hotspot JIT-ing technology was first introduced. Hotspot is a collection of
advanced runtime compilation techniques that, by focussing on the code that
actually runs most often while largely ignoring the rest, are able to use more
advanced optimisations than the old-fashioned, "classic", JIT-er which just
compiled all classes into machine-code without feedback from the runtime.
Because "classic" compiled everything in the same way, there was more pressure
to avoid optimisation that were slow to compute, since they'd be applied
everywhere rather than just where they were needed.

When "hotspot" came out, the previous JIT-er (derived from the Symantek one, I
seem to recall) was renamed "classic".

These names are, of course, ludicrous -- we shouldn't be telling the runtime
what technology we want it to use, but should be telling it what we are going
to do, and let *it* choose the technology. Hence Sun also introduced (I can't
remember if it was at the same time) the "server" and "client" names. As Roedy
has said, the "server" version is intended for applications where startup time
is not important, but heavy-duty optimisation is; whereas the "client" version
is the reverse.

As I understand it, in the current 1.4 from Sun, both "client" and "server" use
Hotspot technology, but differ in the way they are tuned -- the server version
invokes the hotspot optimiser much more readily and makes it work harder (E.g.
in one benchmark I ran, the server version was able to see that the benchmark
result was not used, and optimised all the code away completely, whereas the
"client" version never did reach that level of optimisation, even after the
benchmark had looped several times). I think they also differ in how the
memory allocation/GC algorithms are tuned.

The "classic" and "hotspot" names are now deprecated.

BTW, all these names correspond to different JVM DLLs on Windows (and I assume
that something similar happens in other environments), and other vendors name
their DLLs according to different schemes. That can cause something of a
nuisance if you are running software on a non-Sun JVM if the launcher for that
s/w was coded on the assumption of the Sun naming scheme.

-- chris

 

[Naresh Agarwal]

Hello Chris,

thanks for information.
It seems the "classic" VM is now completely replaced by "HotSpot" VM.
Are there any applications, which will perform better on "classic" wrt
"HotSpot"?

Also could you please tell me a bit about the various vendors of JVM
and which one is most popular?

thanks,
Naresh

 

[Roedy Green]

Are there any applications, which will perform better on "classic" wrt
"HotSpot"?

Some tiny little utility where you ran each method only once without
loops would run better on classic. It would load faster.

 

[Chris Uppal]

Some tiny little utility where you ran each method only once without
loops would run better on classic. It would load faster.

Actually, in such cases it'd be better to turn the JIT-er off entirely and tell
the JVM just to interpret the code. There is a flag for this in the Sun JVMs
but I've forgotten what it is...

-- chris

 

[Chris Uppal]

It seems the "classic" VM is now completely replaced by "HotSpot" VM.
Are there any applications, which will perform better on "classic" wrt
"HotSpot"?

Probably <shrug>. The Hotspot stuff tends to be better in general, though.
But don't forget that Hotspot is only Sun's name for their advanced JIT-ting
technology, other vendors (like IBM) have implementations that are competitive
with Hotspot, but which use different techniques.

Also could you please tell me a bit about the various vendors of JVM
and which one is most popular?

Sun's is the de-facto standard. I doubt if there are many people doing Java
development who don't have a Sun JVM to try stuff on, even if they are
intending their real application to run on a different JVM.

The choice of JVM is determined mostly by the machine/OS your application is
intended to run on. There are JVM vendors that produce implementations for
embedded devices, and other restricted environments. At the other end of the
scale, IBM produces (as far as *I* know) the only JVMs for its mainframes and
other non-PC machines; similarly Sun produces JVMs for its big iron. On
commodity PCs (any OS) there tends to be more choice. IBM and BEA (JRockit)
have implementations that are worth considering. There are others; try google.

-- chris

 

[Brad BARCLAY]

Sun's is the de-facto standard. I doubt if there are many people doing Java
development who don't have a Sun JVM to try stuff on, even if they are
intending their real application to run on a different JVM.

That depends completely on what platforms you're working on, as Sun's
JVM doesn't cover all of them.

Pretty much all of my development is done primarily with JVMs from IBM,
Innotek, and GoldenCode, because Sun doesn't develop a JVM that runs on
my primary development platform.

Brad BARCLAY

 

[Chris Uppal]

Pretty much all of my development is done primarily with JVMs from IBM,
Innotek, and GoldenCode, because Sun doesn't develop a JVM that runs on
my primary development platform.

Ta for the counter-example. What is your development platform ?

-- chris

 

[Brad BARCLAY]

Ta for the counter-example. What is your development platform ?

My primary development platform is still IBM's OS/2. It runs Java
exceedingly well, and has up-to-date JDKs available on it.

I should admit that my other 4 machines are Linux boxes, one of which
acts as the nightly build machine for the jSyncManager Project
(http://www.jsyncmanager.org), and it's running Sun Java 1.4.2 for
Linux. However, that system is running headless, and is completely
automated -- I still do my core development on the OS/2 box.

Brad BARCLAY