RFR(M): 8243392: Remodel CDS/Metaspace storage reservation

[Thomas Stüfe]

On Sat, May 16, 2020 at 12:34 AM <coleen.phillimore at oracle.com> wrote:

>
> One more in-context comment.
>
> On 5/8/20 3:33 AM, Thomas Stüfe wrote:
>
> Hi Ioi,
>
> thanks for taking the time to look at this!
>
> On Fri, May 8, 2020 at 7:37 AM Ioi Lam <ioi.lam at oracle.com> wrote:
>
>> Hi Thomas,
>>
>> I am running your patch in out CI pipeline now. Some comments:
>>
>> [1] Do we still need to use _class_space_list? It looks like we just have
>> a single range. Is _class_space_list->current_virtual_space() always the
>> same VS?
>>
>>   if (_class_space_list != NULL) {
>>     address base =
>> (address)_class_space_list->current_virtual_space()->bottom();
>>     address top = base + compressed_class_space_size();
>>     st->print("Compressed class space mapped at: " PTR_FORMAT "-"
>> PTR_FORMAT ", size: " SIZE_FORMAT,
>>                p2i(base), p2i(top), top - base);
>>
>>
> Yes it is. Has been bugging me for years too. With ccs, the
> VirtualSpaceList is degenerated and only contains one node. It still makes
> some sense code wise. But maybe VirtualSpace*List* is a misnomer.
>
> It also ties in into the question whether Metaspace reservations should be
> able to grow on demand. Oracle folks I talk to tend to say yes. I
> personally think the "Metaspace is infinite don't worry" meme was broken
> since ccs was a thing, since CompressedClassSpaceSize is an absolute limit
> already.
>
> I may tweak and simplify the code a bit with Elastic Metaspace. Maybe, as
> you say, with ccs we can get rid of VirtualSpaceList and deal with the
> range directly. Have to check.
>
>
> Yes, this could be an improvement for a later time.  The compressed class
> space isn't a list.  I think that was the least amount of special code
> place to hook it in at the time.  It makes sense for it to be a single
> VirtualSpaceNode.
>
> CompressedClassSpace + Data (the rest of Metaspace) has a complicated
> relationship for determining high water mark for starting GC, and for
> reporting LowMemory thresholds.  I'd have to look up what was decided there.
>
Data (the rest of Metaspace) does grow on demand unless someone uses
> -XX:MaxMetaspaceSize and then class metaspace size is factored in (maybe
> just committed space not the whole 1G). HTH.
>
>
We stop growing when [committed class space]+[committed data] >=
MaxMetaspaceSize.

CompressedClassSpaceSize is actually completely uninteresting for
calculating limits, it is just an additional, technical limit on the growth
of [committed class space].

Even this equation: MaxMetaspaceSize = CompressedClassSpaceSize+data is
actually not correct, even though the code treats it that way. We could
set CompressedClassSpaceSize much higher than MaxMetaspaceSize, we only
would not be able to commit the whole class space then, but it still would
work. I simplified all this in Elastic Metaspace. GC threshold calculation
is unaffected though.

..Thomas


> Coleen
>
>