RFR: 8241141: Restructure humongous object allocation in G1

[Kim Barrett]

> On Apr 8, 2020, at 4:42 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> On 07.04.20 16:02, Stefan Johansson wrote:
>> New webrevs incorporating the new suggested search from Kim:
>> Full: http://cr.openjdk.java.net/~sjohanss/8241141/02/
>> Inc: http://cr.openjdk.java.net/~sjohanss/8241141/01-02/
> 
> - could you please remove the newline after the return parameter in g1CollectedHeap.cpp:211 while we are touching this code?

Personally, I’d prefer that change not be made.  That line is already fairly long, and that pushes
interesting information even further to the right, where most of the interesting information is more
to the left.  It also makes all three of those lines wrap in my normal 4 buffers across setup.  I know
we don’t have a fixed maximum line length, but that doesn’t mean there aren’t costs.

> There is a distinction between available (for allocation), i.e. visible to the higher layer (e.g. G1CollectedHeap) and committed, which means that its memory is committed from the OS.
> 
> Consider large pages where page size > region size. While G1 may have logically given back some regions in a page to the OS (i.e. these are "unavailable"), G1 might not have been able to actually "uncommit" (give back to the OS) the page and its corresponding regions just yet.
> 
> G1 tracks the difference for various reasons. The use of a second bitmap so that there may be invalid/nonsensical combinations might occur might not have been optimal :)
> 
> I would guess the concurrent uncommit may want to add another state to that, i.e. some "in the process of being uncommitted".
> 
>>>>> I kind of agree, but if we move forward with concurrent uncommit this might change to really mean available rather than committed. We probably want to clear the available map before really uncommitting the regions.
>>>> 
>>>> OK, so “committed” might not be the right term, but “available” doesn’t have the right connotation either, at least for me.  I don’t have a better suggestion just now though.
>>> Yes, we could probably come up with something better.
> 
> I am open to naming improvements :)

“available” still seems like a non-optimal name, but at least now I have a better idea
of where it came from.  Thanks.  I still don’t have a better suggestion, but I’ll think about it.