Re: Sharing GC resources between applications

[ This sat unsent for several months...]

A slightly different biased view.  I spent some years working for a 
company building
a mostly-static Java system.

It is often possible to compile out most of the dynamism in Java 
applications.
Not all, but much.  I think that newer apps are also more dynamic than 
older
apps (as more people learn how to play with classloaders and 
classloader-
exploiting libraries are more widely deployed) which means that this is 
a
moving target.

It is definitely possible to statically compile up all of JRE 1.3.1 into
an image than can be mapped from disk and shared by multiple processes.
Not only have I seen it done, I helped do it.  The VM must of course 
fake the
ordered initialization of classes as they are "loaded", and it's not 
possible
to play games with the bootclasspath in such a system; the VM "starts" 
when
the compilation of the JRE begins, and that's when you must set the boot
classpath.  Getting the behavior right is largely a matter of paying 
strict
attention to the defined semantics of the language and not doing 
anything
more than preconverting bytecodes into machine code.  The practical 
world
of Java programs is sufficiently pathological that the 
bytecode-to-native
compiler must often simply warn of potential problems at compile time,
and generate exception-throwing stubs in case the problematic code is
ever executed.  Except for the disk I/O and JIT compilation, whatever 
would
happen dynamically, is what the generated code should do.  This is 
different
from the way you would do things in a C/C++/Fortran compiler, where 
things
like missing methods or conflicting definitions force you to solve the 
problem
before running the program.

It is possible, but substantially more tricky, to untangle the patterns 
of
classloading performed by some web application servers and pre-compile
those.  There, the classloaders must be assigned at compile-time, and 
not
everything gets precompiled (I recall that JSPs are usually a problem).

I wish it could go without saying, but I know better -- because such 
static
systems are not friendly to the sort of dynamically enabled debugging 
and
profiling games that can be done in a JIT system, they must strive to be
bug-for-bug compatible with the systems where debugging is easy.  In
practice, if there is a difference between two implementations, someone
somewhere will write a program (accidentally or intentionally) that
detects the difference, and even depends on it.  (Different JVMs handled
FP differently on x86; I know of at least three different access-to-lock
patterns that programs can statistically detect; scheduling differences
in two different VMs would expose a race condition in one company's
database code. )

On Mar 21, 2005, at 10:58 PM, David F. Bacon wrote:
> The unfortunate implications of Java's completely dynamic architecture 
> which
> did not allow sharing became obvious as soon as attempts were made to 
> use
> Java for significant applications running outside of web browsers.  
> Java's
> class loading semantics require that a set of classes (which logically
> comprise a library, package, or application) are loaded in the dynamic 
> order
> in which they are referenced.  This severely inhibits the creation of 
> a shar
> able compiled version of a set of classes, which is only exacerbated 
> by the
> nature of JIT compilation.