Name: rmT116609			Date: 08/28/2003


A DESCRIPTION OF THE REQUEST :
[This is related to bug 4416624 (multiple JVM runtimes do not share memory
 between themselves).]
Long time ago, when Smalltalk-80 and other Object languages were created,
I think people never imagine that the heap (the place where Objects are created
and managed) would be so big. Now we can see Java applications using heaps
as big as 2, 8 or 32 GigaBytes, or more. So these old OO languages provided only
ONE heap. And new OO languages (like Java) continue to offer only ONE heap.
Since so many objects in one place entails that collecting garbage may take
minutes, engineers imagined new sophisticated technics for the Garbage Collector:
parallel and concurrent GC, Generational GC, ...
Now there are new problems:
1) Share memory between different JVMs without breaking security.
   See 4416624 about details.
2) Running a JVM on NUMA machines.
   A NUMA machine is made of several blocks of processors. Within each block (a
   set (2, 4, ...) of processors are linked as SMP) the delay for accessing
   physical memory is identical. But the time for accessing physical memory of
   another block is much slower than accessing the physical memory of the block.
   Moreover, if many programs are accessing a lot of data at the same time on
   blocks different from the asking block, then the hardware buses, caches, etc
   can be saturated and performances when accessing physical memory collapse.
   And you know Java programs create MANY threads and A LOT of data, in general.
   Also, the physical memory is allocated on the block where is running the system
   thread that is requiring it. About JVMs, there are different (not standardized)
   ways for implementing how the heap is managed. One possible case is that
   creating memory is not initiated by the system thread associated with the
   Java thread, but by a thread of the Garbage Collector. Since these GC threads
   may have some affinity with a block of processors (be bound on a processor),
   we can see that the physical memory used for storing the bytes of an object
   used by a Java thread may be on a different block than the block where is
   running the system thread associated with the Java thread (with a 1:1 model,
   the most efficient thread model, I think). Add more threads, add more blocks,
   and you can see that all Java threads are trying to access objects that are
   physically stored on other blocks of processors. And we have no way for forcing
   a Java thread to run on a processor (bind on a processor). All of that may
   lead to very bad performances for Java applications on NUMA machines.
3) The heap and the way it is managed are not part of the Java language.

So I think that a way enabling to create and use different heaps would help.
The heap to be used could be associated to Java threads: Each thread would
use a heap, specified at creation or start. (All threads should use the same
heap, by default.) And each heap would be managed by a different instance of
the Garbage Collector.
This way, we could have a set of threads creating new objects in the same heap.
This would help for grouping objects that are supposed to have a short or a long
life.
Also, dividing a very big heap (32 GB) in several smaller heaps (4 or 8 GBs)
would improve performances.
This would help to share a limited an well-know set of objects with another JVM.
This would help to have Java threads accessing data physically allocated by the
same heap manager on the same block of a NUMA machine. (more is required for
forcing the heap managers to run on different blocks).
Classes could be managed as objects and stored in a heap dedicated to them, with
a GC optimized for class management.
Some heaps may have some C-coded ways for managing permanent objects.
This could be transparent with old Java code by using by default a unic heap.

JUSTIFICATION :
- Sharing memory between different JVMs, by means of objects in a heap.
- Improving GC performances when using BIG (> 2 GBs) heaps, by dividing the heap
    in several parts.
- Improving overall performances by grouping long-life objects and short-life
    objects in different heaps.
- Helping improving Java performances on NUMA machines.
- Manage class code as objects, but separately from other objects.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
- Heaps are instances of a new Java class.
- Heaps can be dynamically created (except the default initial heap).
- Thread would be associated with a (potentially) different heap, specified at
	creation or start.
- All threads should use the same heap, by default.
- Each heap would be managed by a different instance of the Garbage Collector.
ACTUAL -
- Only ONE heap is available, where all objects are mixed. Thus leading to
    bad GC performances when a big heap is required (> 2 GB).

(Incident Review ID: 199985) 
======================================================================