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
course.
There are no new ideas here.
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
