tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Miles <>
Subject Re: Challenges for Java hosting
Date Sat, 08 Apr 2006 14:19:42 GMT
Interesting discussion.

> Ideas?  Yes, and it's very simple - use fork()!
The problem with fork() in the way you propose is Garbage Collection.  A 
JVM can move objects and compact heap space during GC, this presents a 
problem that moving data unshare's that page.  For a native executable 
Copy-on-Write provides an improvement on resource usage as memory 
allocation is static once allocated, but between two long running JVMs 
trying to share pages its not so attractive.

The other problem of course is the amount of work a JVM does to load 
byte code, interpret it and ultimately optimize/compile it into machine 
code.  This has additional memory overhead a native executable just does 
not have. The only thing in the data segment of the address space is data.

With linux (maybe others) the native program (and shared libs) is demand 
page loaded from the EXE file on the system, the OS can just drop little 
used code pages knowing it can reload them from a file.  While the 
concept is partially possible with a JVM its just not done.

Any solution on this level is only going to be possible through major 
enhancements at the JVM level against what traditionally Java has been 
about.  ByteCode and GarbageCollection really inhibit traditional 
approaches to the problem, maybe the GCJ project in the not to distant 
will be a faster moving more innovative vehicle for a Java like language 
than Sun Microsystems.

So from that standpoint of throwing away ByteCode for CompiledCode, the 
dynamics of your multiple JVMs become much more like a traditional EXEs.

I would envisage an ideal solution not too different from what you are 
saying.  Java code compiled into fully native code and stored on disk, 
you can then properly share the classes as nature intended between 
multiple JVMs.  Then exactly as you say you have a master JVM in control 
and could dynamically put web-apps into other JVM processes which could 
each dynamically tune their thread and memory usage (on the fly) and as 
a last resort shut down the process to cut it away when its been bad, 
without disrupting the container environment as a whole.  This leads on 
to pooling JVMs to recycle the process to walk around memory leak problems.

With your problem web-app you could make sure he always got his own JVM 
to run in, for the nicer web-apps you could put more than one into a 
slave JVM.  You could make use of shared mapped pages between processes 
and file descriptor passing  to hand off incoming connections.  There is 
no reason the above can't be implemented on both Win32 and Linux in due 

There are no new ideas here.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message