Project proposal: Remove the Permanent Generation

Jon Masamitsu jon.masamitsu at oracle.com
Tue Mar 20 07:40:09 PDT 2012


You may have noticed that this project proposal never got
any farther then this mail.  Somewhat due to indecision on
our part, this work is not going to become its own project
but will be integrated through the hsx/hotspot-gc/hotspot
repository.  We wanted to provide a preview of the work
so prepared this webrev from an recent merge of the perm gen
removal work with hotspot-gc.  We're still working on it
but thought this intermediate webrev would be of interest.

http://cr.openjdk.java.net/~coleenp/metadata2

In this webrev

     Allocations for the class metadata are made from the C heap.
     More work is coming here.  The infrastructure for the perm
     gen has not yet been removed but nothing is allocated in
     the perm gen.

     The klasses that were used to described class metadata have
     been removed (klassKlass and it's derivatives).

     Class metadata type (instanceKlass) has been changed and is
     being separated from oops.  It still derives from Klass but
     Klass now derives from metadataOop and not Klass_vtbl. Please
     note that metadataOop does not derive from oop. In an attempt
     to stay sane we're not changing everything at once.  The
     separation of instanceKlass from oop is being done in a staged
     way and we're not done.  You'll see klassOop, constantPoolOop,
     and constantPoolCacheOop but they are not oops.  For example
     klassOop is typedef'ed to Klass and these types will be renamed
     to remove the Oop extension and capitalize the first letter
     to be consistent with other Hotspot type names.

     instanceKlass, constantPoolOop, and constantPoolCacheOop
     have been restructured to reduce the number of oops they contain.
     constantPoolKlass and cpCacheKlass are gone.

     Data structures have been added to represent class loaders and
     dependencies between class loaders (ClassLoaderData and
     ClassLoaderDataGraph, respectively). Class unloading is directly tied
     to the liveness of the class loaders.

     All the garbage collectors have been modified to find and follow
     oops in class metadata. The work for the CMS collector is not
     complete.

     Changed interpreter to support the move of oops out of the constant
     pool.

     Within the compilers and associated code most of the changes
     involved separating the oop and metadata types, which required
     changes throughout the compiler interface, relocations, dependencies,
     nmethods, debug info and the type systems of the compilers themselves.
     Code generation is for the most part unchanged.


On 11/28/11 09:20, Jon Masamitsu wrote:
> I am going to be proposing the permanent generation
> removal as  a OpenJDK project shortly.  The project is
> described in the JEP 122
>
> http://openjdk.java.net/jeps/122
>
> This is not the formal proposal of the project but rather
> a chance to ask questions ahead of that proposal.


More information about the hotspot-dev mailing list