RFR: Implementation of JEP 387: Elastic Metaspace (round two)

[Thomas Stüfe]

Hi Coleen,

On Fri, Sep 18, 2020 at 2:17 PM Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:

>
> Using the entire MetaspaceArena (used to be SpaceManager) for the class
> metaspace was sort of the simplest thing to do because InstanceKlasses
> aren't fixed size.  If they were, we could have picked something much
> simpler!
> Coleen
>
>
I actually thought about this - what could change if Klass would be
uniform-sized - and I think it would not even simplify that much.

You would have an array of uniform Klass structures living in a
pre-reserved mapping. You don't want to pay upfront so you'd still want to
somehow commit on demand. If only by pushing up a commit boundary like old
metaspace did. You also still need a freelist for unused Klass structures.

I think you would end up with something like the ChunkHeaderPool with added
manual committing, and you would lose the uncommit-on-demand feature the
new metaspace has. Re-using Metaspace instead makes sense. It could even
make sense were the Klass structures uniform in size, complexity-wise.

Cheers, Thomas



> On 9/18/20 8:14 AM, Leo Korinth wrote:
> >
> >>
> >> Finally, why was it chosen that each node could carry precisely two
> >> chunk-roots? It seems somewhat easier to have a one-to-one relation
> >> between chunk-root and VirtualSpaceNode (when we are already so close
> >> to one).
> >>
> >
> > Answering to myself: Because of compressed class space of course. Then we
> > could no longer have one huge VirtualSpaceNode for compressed space, and
> > VirtualSpaceList would need extra logic for allocating into the
> > compressed
> > class address space. Or we would need more levels for the buddy allocator
> > in compressed class space so that it could still be one huge node (with a
> > huge root-chunk). Each of which is a non-trivial change.
> >
> > Sorry for my confusion.
> >
> > Thanks,
> > Leo
>
>