RFR: 8251158: Implementation of JEP 387: Elastic Metaspace

Albert Yang albert.m.yang at oracle.com
Mon Aug 24 10:45:34 UTC 2020

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 {
         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 

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 

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


More information about the hotspot-gc-dev mailing list