jdk 8u40 - MaxMetaspaceSize and CompressedClassSpaceSize

[Vitaly Davidovich]

Hi Ramki,

I agree in principle that a 1GB reservation on 64bit isn't an issue in and
of itself.  The problem comes up, however, if a program is run with ulimit
on VA and someone sized their java app appropriately in, say, java 7.  With
java 8, there can be regressions.

Second, if you disable swap and overcommit on linux, larger virtual mem
allocations may fail.

Having said all that, I'm curious whether there's a way to restrict this
with 1 flag in java 8 and whether the linked documentation is correct or
not.

Thanks

sent from my phone
On Apr 7, 2015 7:26 PM, "Srinivas Ramakrishna" <ysr1729 at gmail.com> wrote:

> Hi Vitaly --
>
> Because reserved but unused virtual address space is, for all practical
> purposes today, irrelevant for 64 bit processes,
> a question to ask is what you see when you do this for 32-bit processes
> (where of course the oop compression
> comments wouldn't of course apply, but the amount of VA space used would
> be much more relevant and parsimony
> -- or lack thereof -- in VA space reservation would visibly affect the
> bottom-line in a 32-bit VA space).
>
> -- ramki
>
> On Tue, Apr 7, 2015 at 12:27 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> Hi guys,
>>
>> It seems that putting a cap on MaxMetaspaceSize has no impact on amount of
>> memory reserved *unless* CompressedClassSpaceSize is also set.  For
>> example,
>>
>> java -Xmx64m -XX:MaxMetaspaceSize=16m Test
>>
>> yields the following:
>>
>>  Metaspace       used 2421K, capacity 4486K, committed 4864K, reserved
>> 1056768K
>>   class space    used 261K, capacity 386K, committed 512K, reserved
>> 1048576K
>>
>> Adding -XX:CompressedClassSpaceSize=16m yields:
>>
>> Metaspace       used 2421K, capacity 4486K, committed 4864K, reserved
>> 24576K
>>   class space    used 261K, capacity 386K, committed 512K, reserved 16384K
>>
>> According to
>>
>> http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html
>> :
>>
>> >
>> > If UseCompressedOops is turned on and UseCompressedClassesPointers is
>> > used, then two logically different areas of native memory are used for
>> > class metadata. UseCompressedClassPointers uses a 32-bit offset to
>> > represent the class pointer in a 64-bit process as does
>> UseCompressedOops for
>> > Java object references. A region is allocated for these compressed class
>> > pointers (the 32-bit offsets). The size of the region can be set with
>> > CompressedClassSpaceSize and is 1 gigabyte (GB) by default. The space
>> for
>> > the compressed class pointers is reserved as space allocated by mmap at
>> > initialization and committed as needed. The MaxMetaspaceSize applies to
>> > the sum of the committed compressed class space and the space for the
>> other
>> > class metadata.
>>
>>
>> Unless I'm misunderstanding, the last sentence there seems to imply that
>> MaxMetaspaceSize would put a cap on the compressed class space as well.
>> Or
>> is the "committed" part of the last sentence the key? There's no way to
>> cap
>> the *reserved* amount with 1 flag? Basically, what's the java 8 equivalent
>> to MaxPermSize=X in java 7 and earlier?
>>
>> The reason this came up is because java 8 seems to have a much higher
>> virtual mem reserve charge than java 7, even for an app with a simple main
>> that does nothing, and metaspace/compressed class space reservation
>> appears
>> to be the biggest contributor.
>>
>> Thanks
>>
>
>