Name: ddT132432 Date: 10/05/2001


This is a feature request and thus applies to any new version of the Java
Runtime.

Although there are other bugs and rfe's on this topic, I don't think any
address a reasonably simple solution that has seen wide use on all operating
systems. The use of shared memory for executable code.

Any operating system of considerable size has thousands of shared libraries
that are loaded when any given application is started up. Executable code in
these libraries is loaded once, upon the first request of that library, and
subsequent requests use the previously loaded code. Instance-specific data,
such as variables local to a given process, are still initialized and
manipulated on a per-process basis.

When a java application loads, thousands of classes are loaded just to start up
the runtime, and thousands more are loaded to support whatever application is
being run. The difference in this case is that these class definitions are
loaded into memory once for each runtime process, resulting in a massive waste
of system memory.

The simplest and (imho) most elegant solution would be to provide, at a runtime
level, support for loading class definitions into a global memory space. Thus,
the first JVM that loads would populate this memory space with base system
classes, and subsequent applications would similarly populate it with
application-specific classes.

In essence:
1. The classloader would load all classes to and from the global memory space,
shared across all JVMs. Subsequent requests to load or execute a class would
use the definition loaded into shared memory, preventing classes from being
loaded into the process memory of every single JVM
2. Static fields and code in the class would be initialized and executed on a
per-process basis...i.e. when a runtime first accessed a class in global
memory, static initializers and code would be executed in local process memory.
Static fields would be stored in process memory to prevent processes from
stepping on one another.
3. Naming conflicts could arise, but could be prevented by qualifying classes
in the global memory space with the location they were loaded from. For
example: Application A starts up first, and loads com.mypack.MyClass from
C:\MyPack.jar. Application B starts up later and loads com.mypack.MyClass (not
identical) from C:\MyPack2.jar. A naming conflict in the global memory space
would be prevented by tracking which jar file, system, or network location a
given class was loaded from. Adding location guarantees a class to be unique in
global memory.
4. Version conflicts could arise, if two applications A and B use a given
class, B stops, the class is updated, and B starts again. However, the global
memory store would take into account the serial ID or timestamp of a given
classfile. A would continue to use the version that it caused to be loaded into
global memory, while B would result in a new class entry being added for the
new version. When application A terminated, the old class version would be
unloaded.

What makes a solution like this even more interesting now is the addition of
Shared Memory support in the NIO classes of JDK 1.4. With tweaking, the JVM
could be modified to access all class executable information from shared
memory, keeping static information locally. The process would be entirely
transparent to any user or developer, aside from the fact that 15MB of class
data would only be loaded *once*. It even opens up the possibility of a single
runtime starting up at system launch, speeding up the loading of all subsequent
applications (since base system classes would be loaded already). Any java user
or developer I know would sacrifice a one-time allocation of 15, 25, or even
50MB of memory if every application used after that time had a much smaller
memory footprint.

  From what I have read of the JDK source, it seems like this solution is
extremely feasible. The classloading and execution all stems from single pieces
of code, which could easily be modified to leave executable code in share
memory.

This is my best suggestion for solving the great Java memory problems.
(Review ID: 133233)
======================================================================