RFR: 8170395: Metaspace initialization queries the wrong chunk freelist

Thomas Stüfe thomas.stuefe at gmail.com
Mon Nov 28 16:58:37 UTC 2016

On Mon, Nov 28, 2016 at 5:45 PM, Mikael Gerdin <mikael.gerdin at oracle.com>

> Hi Stefan,
> On 2016-11-28 14:52, Stefan Karlsson wrote:
>> Hi all,
>> Please, review this patch to fix metaspace initialization.
>> http://cr.openjdk.java.net/~stefank/8170395/webrev.01/
> Overall I think this change looks good.
> One thing I noticed is that the first parameter to
> VirtualSpaceList::get_new_chunk
> is actually ignored so you might want to just get rid of it, it's just
> confusing to see it. If you decide to do something about get_new_chunk I
> think it wouldn't hurt to have the names of the parameters changed as well,
> "grow_chunks_by_words" is actually "requested_chunk_size" and
> "medium_chunk_bunch" could be something like "suggested_commit_granularity"
+1 to that, this would make the code quite a bit clearer.

I also had a hard time understanding the "make_current" flag in
SpaceManager::add_chunk() until I (hope I) understood that it only matters
for humongous chunks where we differentiate between (a) preallocating a
still-unused humongous chunk for future allocations (initial chunk) or (b)
allocating a humongous chunk for immediate consumption by a
larger-than-medium-chunk memory request. I never saw (b) in real life,
however, the only humongous chunks I ever see are the initial chunks. Does
this ever happen?

> You might want to make the "const size_t" constants you moved out of the
> enum to either be "static" (which would be static in the C-sense) or add
> them in an anonymous namespace since otherwise they will pollute the global
> symbol namespace (more so than an enum which is strictly file scoped).
> The rest of the change looks good to me.
> /Mikael
> https://bugs.openjdk.java.net/browse/JDK-8170395
>> The fix for JDK-8169931 introduced a new assert to ensure that we always
>> try to allocate chunks that are any of the three fixed sizes
>> (specialized, small, medium) or a humongous chunk (if it is larger then
>> the medium chunk size).
>> During metaspace initialization an initial metaspace chunk is allocated.
>> The size of some of the metaspace instances can be specified on the
>> command line. For example:
>> java -XX:InitialBootClassLoaderMetaspaceSize=30720 -version
>> If this size is smaller than the medium chunk size and at the same time
>> doesn't match the specialized or small chunk size, then we end up
>> hitting the assert mentioned above:
>> #
>> # Internal Error
>> (/scratch/opt/jprt/T/P1/142848.erik/s/hotspot/src/share/vm/
>> memory/metaspace.cpp:2359),
>> pid=31643, tid=31646
>> # assert(size > free_chunks(MediumIndex)->size()) failed: Not a
>> humongous chunk
>> #
>> ========================================================================
>> The most important part of the fix is this line:
>> +  // Adjust to one of the fixed chunk sizes (unless humongous)
>> +  const size_t adjusted = adjust_initial_chunk_size(requested);
>> which ensures that we always request either of a specialized, small,
>> medium, or humongous chunk size, even if the requested size is neither
>> of these.
>> Most of the other code is refactoring to unify the non-class metaspace
>> and the class metaspace code paths to get rid of some of the existing
>> code duplication, bring the chunk size calculation nearer to the the
>> actual chunk allocation, and make it easier to write a unit test for the
>> new adjust_initial_chunk_size function.
>> ========================================================================
>> The patch for JDK-8169931 was backed out with JDK-8170355 and will be
>> reintroduced as JDK-8170358 when this patch has been reviewed and pushed.
>> Testing: jprt, unit test, parts of PIT testing (including CDS tests),
>> failing test
>> Thanks,
>> StefanK

More information about the hotspot-dev mailing list