Sharing these data structures will significantly reduce the VM-specific
footprint and thus allow many more VMs to run simultaneously for a given
amount of memory. We will investigate "skim-the-cream" solutions that
will allow us sharing bytecodes across VMs.



  xxxxx@xxxxx   2001-12-03
Clarification for Mantis relase ...

-) Includes sharing of HotSpot internal data structures across java processes.
-) Shared structures include symbolOops and methodOops (which include
   bytecodes).  Other class definition related structures are shared up to 
   the point in time where they need to be modified (then private copies 
   are made).
-) Since these objects appear in the Java heap, the proposal uses a 
   "shared generation" in the heap.

N/A

Committing to merlin release


======================================================================
  xxxxx@xxxxx   2001-12-03
Committed to hopper release.


  xxxxx@xxxxx   2002-07-22
Closed as a duplicate of 4416624, which describes sharing of class 
descriptions (including constant pools).

In my humble opinion, this bug/RFE (a matter of taste), is
closely related to the following bug/RFE ids:

4187333 (38 votes)
<this one> ( 2 votes)
4353002 ( 3 votes, closed as a duplicate of 4287407)
4416624 (56 votes)
4511554 ( 3 votes)

Sums up as 102 votes, why not keep just one of the items as
open and put all votes on that one?

Looking at 4287407 it seemed to be scheduled for "Merlin"
which I think became released as J2SE SDK 1.4.0 but I can
not se that one as "solved" in the 1.4.0 release notes.

This is part of the general memory-usage disaster, se
item 4466510 which now has 675 votes, being the third most
popular open RFE.

How much of the memory problem is an implementation "only"
issue. Is there any language or JVM spec changes needed? Do
anyone know of other JVM implementations (IBM, JRockit,
...) that is more lean on memory than Sun's JVM?

Kind regards

Tomas