[gclist] Sharing GC resources between applications
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
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
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
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
> did not allow sharing became obvious as soon as attempts were made to
> Java for significant applications running outside of web browsers.
> class loading semantics require that a set of classes (which logically
> comprise a library, package, or application) are loaded in the dynamic
> 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