Process and threads

[Jules Bean]

On Wed, 3 Mar 1999, Adam Messer wrote:

> Hello,
> 
> I am in an R&D group at my company. Our current
> research project is a clustered Java environment I have been using Kaffe
> as a basis to understand JVMs. I assume that the way Kaffe handles things
> is pretty typical of JVMs in general. I have a few questions about JVMs
> in general, and Kaffe specifically. I hope it is OK to ask these questions
> here. Anyone who is a JVM expert, please feel free to sound off on this
> subject.

I'm certainly not an expert, but I'll start the ball rolling.

> 
> I am confused about a few things. First, how do JVMs
> like Kaffe and Sun's compare the built in JVMs of browsers like Netscape?

There should be no fundamental differences.  For example, Apple's JVM
(MacOS for Java, it is bizarrely called, I think) will operate to run
applications, and also will be used by MSIE, if you configure MSIE thusly.

The only real difference, then, is that browser JVMs run applets, and
standalone JVMs run applications.  But that's really no more than a
difference in calling conventions.  And note that most standalone JVMs
contain a java application called appletviewer which will run applets.

> Specifically, I am interested in issues like 1) their lifetimes, 2)  how
> they handle processes. It looks as if a JVM like Kaffe only handles on
> process. I see a couple of  'fork/exec' functions defined in the
> code, but they never seem to get called? 

In general, if your code is 'pure java', then you don't fork.  If you wish
to use parallel processing in java, you use its built-in thread system.
Most java runtimes include the System.exec() call (which is parallel to
the ANSI C 'system()' call), but this is most commonly used to run
non-java programs.

> If you run the JVM from the command line, how would you specify another
> application to run anyone. It looks like the only time that a process
> gets created is when you invoke Kaffe (or any other JVM) to load an
> application. 

AFAIK, a process is never created by kaffe.  When you use kaffe to run a
java application, your operating system shell creates a process - the
kaffe process.  The kaffe process then initialises its VM, and loads the
java app.


> The first difference I notice between an application and an applet is
> that an application has a main()  entry point. Is that correct? What are
> the other important differences from the process/thread point of view. 

There no other important differences.  The differences are calling
conventions, and the fact that an applet already has a graphical context
when it is initialised - it lives inside some GUI window created for it.

> Would Kaffe (or any JVM) start another process (fork/exec) if a request
> is made to load an object that has a main()  in it. 

Never.  Far more sophisticated communication is possibly between two java
threads in the same VM, after all. 


> Command line JVMs exit when the application they start exits. Does
> anyone have a comment on the resident JVM of Linux? How/why does Linux
> do that.

AFAIK, it doesn't do that :)  Linux has 'java support' - but my
understanding of that support is merely that the kernel knows how to
execute class files by spawning a JVM.  I'm pretty sure it doesn't have a
resident one.


> It seems like a great idea if the machine in question will be spending
> most of its time running Java applications. Does anyone know if any of
> the 'built in' JVMs of HTTP servers ever remain resident. 

I would expect they do.  I've never played with them, though.

> It looks like the only purpose of command line JVMs is for development
> and debug of Java applications and applets. Is that true.

Not really, no.  I use a command line JVM to run java applications, too.
(Aside: what do you mean by 'command-line'?  I can launch my JVM by
clicking an icon, too... but I can launch any application by clicking an
icon, just as I can from the command-line).

> Can anyone give an overview of server side JVMs .vs. client side JVMs? 

In general, they're solving totally different problems:

Client side JVM:

Address the fact that HTML is static, and enable the systems designer to
implement sophisticate client-side interaction, including a proper GUI
interface, network communications, and so forth.  

Server side JVM:

Simply work on the principle that Java's a pretty cool language from an
engineering point of few (automatic memory management, exception handling,
etc.) and is very fast in execution (particularly with JIT technologies).
So server side JVM is comparable to the idea of embedding perl or VB in
your server (like Active Server Pages).

Hope that helps,

Jules

/----------------+-------------------------------+---------------------\
|  Jelibean aka  | jules at jellybean.co.uk         |  6 Evelyn Rd	       |
|  Jules aka     | jules at debian.org              |  Richmond, Surrey   |
|  Julian Bean   | jmlb2 at hermes.cam.ac.uk        |  TW9 2TF *UK*       |
+----------------+-------------------------------+---------------------+
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |
\----------------------------------------------------------------------/