MaxMetaspaceSize and CompressedClassSpaceSize

[Stefan Karlsson]

On 2015-06-12 02:57, Jon Masamitsu wrote:
>
>
> On 6/11/2015 5:09 PM, Yasumasa Suenaga wrote:
>> Hi Jon,
>>
>>> Please send the hs_err log.  It will have a better description of 
>>> the heap.
>> This is not crash (OutOfMemoryError). So I do not have hs_err log.
>>
>>
>>> The CompressedClassSpaceSize is the size reserved for the Class 
>>> space.  The
>>> size of the compressed-class-space is included in the comparison with
>>> MaxMetaspaceSize
>>> only when the space is committed.  So no, it should not be compared 
>>> to the
>>> MaxMetaspaceSize at initialization.
>> Reserved memory will affect overcommit memory in OS.
>> In case of Linux, it may cause of OOM-killer.
>> So I want to check CompressedClassSpaceSize before initialization.
>>
>>> I would fix this in share/vm/memory/metaspace.cpp
>>>
>>> Metaspace::global_initialize()
>>>
>>> in the calculation of _first_chunk_word_size.
>>>
>>>        _first_chunk_word_size = 
>>> MIN2(InitialBootClassLoaderMetaspaceSize,
>>> MaxMetaspaceSize) / BytesPerWord;
>> Thank you for your suggestion.
>> May I file it to JBS?
>
> I don't think that limiting  CompressedClassSpaceSize by 
> MaxMetaspaceSize is a good
> thing to do.  Certainly not on systems which don't have OOM-killer. 
> There is an easy work around
> and sometimes it is better to use the workaround than to make the JVM 
> do something
> automatically that may seem right in some situations but may not be 
> right in others.

The proposed patch breaks the usage of the -XX:MaxMetaspaceSize flag.

$ ../build/linux-x86_64-normal-server-release/jdk/bin/java 
-XX:MaxMetaspaceSize=128m
Error occurred during initialization of VM
Sum of InitialBootClassLoaderMetaspaceSize and CompressedClassSpaceSize 
should be less than MaxMetaspaceSize.


We talked about something similar in this thread:
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-April/014425.html

where I wrote:
"However, as you've noted we pre-reserve 1GB, and not 32 MB, for the 
compressed class space. That can be fixed by either running with 
-XX:CompressedClassSpaceSize=32m, or by a patch to change the 
implementation to only reserve MIN(CompressedClassSpaceSize, 
MaxMetaspaceSize) for the compressed class space.

Maybe it would be enough for you to implement the suggested 
MIN(CompressedClassSpaceSize, MaxMetaspaceSize) patch?

StefanK

>
> You are, of course,  free to file a JBS and have it considered by more 
> than just me.
>
> Jon
>
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2015/06/12 4:01, Jon Masamitsu wrote:
>>> On 06/11/2015 03:52 AM, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> I booted Tomcat 8 with "-XX:MaxMetaspaceSize=5m -XX:+PrintGCDetails",
>>>> but it failed.
>>>> I checked GC log, Java heap and Metaspace was NOT exhausted.
>>> Please send the hs_err log.  It will have a better description of 
>>> the heap.
>>>
>>>> ------------
>>>> [Full GC (Last ditch collection) [Tenured: 1049K->1049K(10944K), 
>>>> 0.0050992 secs] 1049K->1049K(15936K), [Metaspace: 
>>>> 4871K->4871K(1056768K)], 0.0051411 secs] [Times: user=0.01 
>>>> sys=0.00, real=0.00 secs]
>>>> [Full GC (Metadata GC Threshold) [Tenured: 1049K->1049K(10944K), 
>>>> 0.0050587 secs] 1049K->1049K(15936K), [Metaspace: 
>>>> 4871K->4871K(1056768K)], 0.0051023 secs] [Times: user=0.00 
>>>> sys=0.00, real=0.01 secs]
>>>> [Full GC (Last ditch collection) [Tenured: 1049K->1049K(10944K), 
>>>> 0.0050200 secs] 1049K->1049K(15936K), [Metaspace: 
>>>> 4871K->4871K(1056768K)], 0.0050613 secs] [Times: user=0.01 
>>>> sys=0.00, real=0.00 secs]
>>>>
>>>> Exception: java.lang.OutOfMemoryError thrown from the 
>>>> UncaughtExceptionHandler in thread "main"
>>>> ------------
>>>>
>>>> My environment:
>>>>      Fedora22 x86_64
>>>>       - kernel-4.0.4-303.fc22.x86_64
>>>>       - glibc-2.21-5.fc22.x86_64
>>>>       - java-1.8.0-openjdk-1.8.0.45-39.b14.fc22.x86_64
>>>>       - apache-tomcat-8.0.23
>>>>
>>>> This java process is enabled CompressedClassSpace (as default).
>>>> Metaspace size in GC log seems to be contained it (1GB).
>>>>
>>>> I checked arguments.cpp and metaspace.cpp, CompressedClassSpaceSize
>>>> does not seem to be checked consistent with MaxMetaspaceSize.
>>>>
>>>> Does JVM have to check CompressedClassSpaceSize and 
>>>> InitialBootClassLoaderMetaspaceSize
>>>> which are consistent with MaxMetaspaceSize?
>>> The CompressedClassSpaceSize is the size reserved for the Class 
>>> space.  The
>>> size of the compressed-class-space is included in the comparison with
>>> MaxMetaspaceSize
>>> only when the space is committed.  So no, it should not be compared 
>>> to the
>>> MaxMetaspaceSize at initialization.
>>>
>>>> I think we can fix as below:
>>>> ------------
>>>> diff -r 85e2c3553384 src/share/vm/runtime/arguments.cpp
>>>> --- a/src/share/vm/runtime/arguments.cpp        Wed Jun 03 08:49:34 
>>>> 2015 +0900
>>>> +++ b/src/share/vm/runtime/arguments.cpp        Thu Jun 11 19:50:11 
>>>> 2015 +0900
>>>> @@ -2333,6 +2333,15 @@
>>>>       status = status && verify_interval(CompressedClassSpaceSize, 
>>>> 1*M, 3*G,
>>>> "CompressedClassSpaceSize");
>>>>
>>>> +  if (UseCompressedClassPointers) {
>>>> +    status = status &&
>>>> +         ((CompressedClassSpaceSize + 
>>>> InitialBootClassLoaderMetaspaceSize)
>>>> + <= MaxMetaspaceSize);
>>>> +  } else {
>>>> +    status = status &&
>>>> +                (InitialBootClassLoaderMetaspaceSize <= 
>>>> MaxMetaspaceSize);
>>> I would fix this in share/vm/memory/metaspace.cpp
>>>
>>> Metaspace::global_initialize()
>>>
>>> in the calculation of _first_chunk_word_size.
>>>
>>>        _first_chunk_word_size = 
>>> MIN2(InitialBootClassLoaderMetaspaceSize,
>>> MaxMetaspaceSize) / BytesPerWord;
>>>
>>>
>>> Jon
>>>
>>>
>>>
>>>> +  }
>>>> +
>>>>       status = status && verify_interval(MarkStackSizeMax,
>>>>                                       1, (max_jint - 1), 
>>>> "MarkStackSizeMax");
>>>>       status = status && verify_interval(NUMAChunkResizeWeight, 0, 
>>>> 100, "NUMAChunkResizeWeight");
>>>> ------------
>>>>
>>>>
>>>> If it is accepted as a bug, I will file it to JBS and upload webrev.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>