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 {
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
More information about the hotspot-runtime-dev
mailing list