what is difference between client, server 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

[Brad BARCLAY]

Naresh Agarwal wrote:

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?

"Client" and "Server" are actually just types of HotSpot compilers,
optimized for use on "Clients" and "Servers". For more on HotSpot
technology, try the following URL:

http://java.sun.com/products/hotspot/

Brad BARCLAY

--
=-=-=-=-=-=-=-=-=
From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
The jSyncManager Project: http://www.jsyncmanager.org


[FISH]

na******@informatica.com (Naresh Agarwal) wrote in message news:<2b**************************@posting.google. com>...

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?

The differences generally relate to the way bytecode (used by Java
classes) is translated into native machine code (used by your computer's
processor!)

The nitty-gritty of each method is too much to expect someone to go into
here, but JVM's fall into two very broad categories: ones which interpret
the bytecode, and ones which attempt to 're-write' bytecode sections into
platform specific machine code, so they can be run more efficiently. The
latter option has two strategies: quickly compile each method prior to it
being executed, or analyse the application as it runs, and use this
information to help create tighter and more efficient machine code.
(Quick and crude, versus slow and elegant, if you like!)

For short lived programs, like many client applications, using the first
strategy to quickly speed up the application is often preferred. For
long-life applications, like network server software which can be active
for weeks or months at a time, slower execution during the first few
hours is a small price to pay for enhanced efficiency later on - so the
second strategy is often preferred.

Naturally this is a big topic, and which mode you choose will depend upon
other factors, including the type of work your application does, and how
it does it. The description above is nothing more than a broad overview.
Try searching java.sun.com for more details on each 'mode', including
pro's and con's for each.
-FISH- ><>

[Naresh Agarwal]

thanks for reply.

The second category you are referring to is JIT, right??

Does JIT compilers first compile the *entire* bytecode into machine
code and then starts execution?? If yes, then why these are called as
*Just In Time*?

Also the normal interpreters (first category I guess) also needs to
compile all the bytecode. Thus comilation will be required by both
interpreters as well as JIT compliers. Then why does JIT compilers are
slower then interpreters in certain situations?

thanks,
Naresh
jo*****@merseymail.com (FISH) wrote in message news:<db***********************@posting.google.com >...

na******@informatica.com (Naresh Agarwal) wrote in message news:<2b**************************@posting.google. com>...

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?

The differences generally relate to the way bytecode (used by Java
classes) is translated into native machine code (used by your computer's
processor!)

The nitty-gritty of each method is too much to expect someone to go into
here, but JVM's fall into two very broad categories: ones which interpret
the bytecode, and ones which attempt to 're-write' bytecode sections into
platform specific machine code, so they can be run more efficiently. The
latter option has two strategies: quickly compile each method prior to it
being executed, or analyse the application as it runs, and use this
information to help create tighter and more efficient machine code.
(Quick and crude, versus slow and elegant, if you like!)

For short lived programs, like many client applications, using the first
strategy to quickly speed up the application is often preferred. For
long-life applications, like network server software which can be active
for weeks or months at a time, slower execution during the first few
hours is a small price to pay for enhanced efficiency later on - so the
second strategy is often preferred.

Naturally this is a big topic, and which mode you choose will depend upon
other factors, including the type of work your application does, and how
it does it. The description above is nothing more than a broad overview.
Try searching java.sun.com for more details on each 'mode', including
pro's and con's for each.
-FISH- ><>

[FISH]

na******@informatica.com (Naresh Agarwal) wrote in message news:<2b**************************@posting.google. com>...

thanks for reply.

The second category you are referring to is JIT, right??
It includes JIT, yes, and Hotspot.

Does JIT compilers first compile the *entire* bytecode into machine
code and then starts execution?? If yes, then why these are called as
*Just In Time*?
My understanding is that it compiles each method just prior to its
execution. Uncalled methods will therefore never get translated to
machine code.

Also the normal interpreters (first category I guess) also needs to
compile all the bytecode. Thus comilation will be required by both
interpreters as well as JIT compliers. Then why does JIT compilers are
slower then interpreters in certain situations?

The basic interpreter style JVM's don't actually compile their code,
as such. They operate more akin to interpreters like you'd find with
a scripting language. The difference is that bytecode is much closer
to 'the machine' than lines of source code, so the huge parsing over-
head is not present. When used like this, the JVM is like an
emulator,
in the same way that one might run a Commodore 64 emulator on a PC.

As for why JIT code might run slower - that is a complex issue, with
I suspect many possible answers. One obvious circumstance which would
disadvantage the JIT would be if you had a program with a
straight-line execution path - no loops of any great size or few
methods which get
called repeatedly. Translating a method to native code carries an
overhead. If the method (or indeed loop content) isn't called often
enough to justify that overhead, then the expense of JIT compilation
is never recouped.

In reality, however, none but the most trivial of Java programs are
likely to be so 'straight-line' as to not benfit from compilation to
native code.
-FISH- ><>