RFR: 8251158: Implementation of JEP 387: Elastic Metaspace

[Albert Yang]

Hi Thomas,

 > Enlarging the chunk has nothing to do with reservation.

I didn't mean reserving the virtual space; instead, the chunk is "reserved" and can't be 
used for later allocation. Using `MetaspaceArena::allocate` to illustrate my point.

```
     if (current_chunk()->free_words() < raw_word_size) {
       if (!attempt_enlarge_current_chunk(raw_word_size)) { // step 1: reserve the chunk; 
assume the current chunk is 64K, and after enlarging, it becomes (64+64) K.
         current_chunk_too_small = true;
       } else {
         DEBUG_ONLY(InternalStats::inc_num_chunks_enlarged();)
         UL(debug, "enlarged chunk.");
       }
     }

     // Commit the chunk far enough to hold the requested word size. If that fails, we
     // hit a limit (either GC threshold or MaxMetaspaceSize). In that case retire the
     // chunk.
     if (!current_chunk_too_small) {
       if (!current_chunk()->ensure_committed_additional(raw_word_size)) { // step 2: 
commit to physical memory, if fails, the newly "reserved" 64K is leaked, right?
         UL2(info, "commit failure (requested size: " SIZE_FORMAT ")", raw_word_size);
         commit_failure = true;
       }
     }
```

The step 2, if failed, needs to undo step 1. That's what I meant that step 1 and 2 are 
tightly-coupled.

Maybe leaking 64K in virtual address is not that significant. Better explain it in the 
comments so that future readers know this problem is known.

 > When putting out a new webrev, it will come with an updated version of the review 
guide. The master data for both are kept at github: 
https://github.com/tstuefe/jep387/tree/master/review in case openjdk.java.net is not 
reachable.

Thank you very much; the new guide is even better than the version I originally followed.

-- 
/Albert