[gclist] Sharing GC resources between applications

David Chase dr2chase at mac.com
Tue May 24 16:38:17 PDT 2005

[ 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 
Not all, but much.  I think that newer apps are also more dynamic than 
apps (as more people learn how to play with classloaders and 
exploiting libraries are more widely deployed) which means that this is 
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 
to play games with the bootclasspath in such a system; the VM "starts" 
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 
attention to the defined semantics of the language and not doing 
more than preconverting bytecodes into machine code.  The practical 
of Java programs is sufficiently pathological that the 
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 
happen dynamically, is what the generated code should do.  This is 
from the way you would do things in a C/C++/Fortran compiler, where 
like missing methods or conflicting definitions force you to solve the 
before running the program.

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

I wish it could go without saying, but I know better -- because such 
systems are not friendly to the sort of dynamically enabled debugging 
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.

More information about the GClist mailing list