RFR: JDK-8262074: Investigate defaults for MetaspaceSize

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: JDK-8262074: Investigate defaults for MetaspaceSize

Thomas Stuefe
I was looking at whether the default values for MetaspaceSize (the initial threshold to start off a metaspace-motivated GC) still make sense after JEP-387.

The default is dependent on compiler tier and bitness. It is also spread across all platforms.

In addition to that, it also may get modified after Metaspace::ergo_initialize() in client-compiler-emulation-mode:

https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/hotspot/share/compiler/compilerDefinitions.cpp#L194-L196

which is unexpected and causes confusion (eg JDK-8261907, JDK-8261907).

The reasons for this seem to originate from PermGen times:
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-February/045536.html

----

Today, MetaspaceSize defaults to:

- no compiler (eg Zero):      **4M** (32bit)   **5.19M** (64bit)
- C1-only build:     **12M**
- C1+C2 build (standard):    **16M** (32bit) **20,75M** (64bit)

I was surprised to see that they do not depend on any compiler *runtime* switches. It only depends on build time decisions.

---

How much do we use? I analyzed a simple java app to see the difference VM settings make on initial metaspace consumption. Committed space, used in brackets:


(Note:                  (used)          committed
CDS on:

64bit:       (181,58 KB)     384 KB  (a)
64bit tier1 only:       (170,04 KB)     384 KB
64bit Xint: (16,62 KB)      256 KB

32bit     (178 KB)        256 KB
32bit tier1 only: (144 KB)        256 KB
32bit Xint: (11 KB) (b)     128 KB  

CDS off:

64bit: (5,06 MB)       5.62 MB
64bit tier1 only:       (5,00 MB)       5,56 MB
64bit Xint: (4,84 MB)       5.44 MB

32bit     (3,69 MB)       3.75 MB
32bit tier1 only: (3,65 MB)       3.75 MB
32bit Xint: (3,52 MB)       3.62 MB

Class space on/off

CDS off, 64bit, +CompressedClassPointers: 5.44M
CDS off, 64bit, -CompressedClassPointers: 5.38M


_Notes:
(a) Since JEP-387, with CDS=on, we pay very little committed footprint upfront (384K). For comparison, JDK 15 commits here 5.75M.
(b) The seemingly high difference between Xint and C1+C2 - 11K vs 178K - is misleading: All initial classes get compiled, but since most of their metadata live in CDS, not in Metaspace, all we allocate at the start are MethodCounters. Hence, with -Xint, we almost allocate nothing. That changes as soon as we start loading application classes._

Conclusions:
- CDS=off increases metaspace footprint by a flat amount, in my case ~5MB, which makes sense.
- Running with (any) compiler has not much influence once we start using Metaspace for real. The difference between C1-only and C1+C2 is neglectible, the difference between Xint and C1+C2 amounts to about 2% wrt to initial metaspace consumption.
- Running with or without compressed Klass pointers makes not much difference. With class space, we pay for certain overhead twice, but at this early stage this is not noticeable.
- The difference between 64bit and 32bit is more like 1.4-1.5, not the 1.3 factor we currently assume

-----

Proposal:

1) I propose to make MetaspaceSize independent from compiler. For one, if the intention was to have a lower threshold with compilers deactivated, that has never worked. E.g. on 64bit we always had a threshold of 20.75MB regardless of Xint/TieredStopAtLevel. Even if it worked, the compiler does not make that much difference in metaspace footprint.

2) I propose to slightly lower MetaspaceSize - on 32bit from 16M to 14M, on 64bit from 20.75M to 20M. This takes the slightly lower metaspace footprint since JEP 387 into account (less waste) and the scale I found to be higher than 1.3.

This is all very cautious. For the standard VM, very little changes, so this is mainly a cleanup patch. We could probably tune MetaspaceSize down to much lower levels. And/or make size it differently depending on UseSharedSpaces. However, atm I don't have time to hunt regressions due to too early GCs.

-----

Tests: GA, nightlies at SAP

-------------

Commit messages:
 - Start

Changes: https://git.openjdk.java.net/jdk/pull/2675/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2675&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262074
  Stats: 28 lines in 13 files changed: 0 ins; 27 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2675.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2675/head:pull/2675

PR: https://git.openjdk.java.net/jdk/pull/2675
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8262074: Investigate defaults for MetaspaceSize

Ioi Lam-2
On Mon, 22 Feb 2021 16:08:20 GMT, Thomas Stuefe <[hidden email]> wrote:

> I was looking at whether the default values for MetaspaceSize (the initial threshold to start off a metaspace-motivated GC) still make sense after JEP-387.
>
> The default is dependent on compiler tier and bitness. It is also spread across all platforms.
>
> In addition to that, it also may get modified after Metaspace::ergo_initialize() in client-compiler-emulation-mode:
>
> https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/hotspot/share/compiler/compilerDefinitions.cpp#L194-L196
>
> which is unexpected and causes confusion (eg JDK-8261907, JDK-8261907).
>
> The reasons for this seem to originate from PermGen times:
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-February/045536.html
>
> ----
>
> Today, MetaspaceSize defaults to:
>
> - no compiler (eg Zero):      **4M** (32bit)   **5.19M** (64bit)
> - C1-only build:     **12M**
> - C1+C2 build (standard):    **16M** (32bit) **20,75M** (64bit)
>
> I was surprised to see that they do not depend on any compiler *runtime* switches. It only depends on build time decisions.
>
> ---
>
> How much do we use? I analyzed a simple java app to see the difference VM settings make on initial metaspace consumption. Committed space, used in brackets:
>
>
> (Note:                  (used)          committed
> CDS on:
>
> 64bit:       (181,58 KB)     384 KB  (a)
> 64bit tier1 only:       (170,04 KB)     384 KB
> 64bit Xint: (16,62 KB)      256 KB
>
> 32bit     (178 KB)        256 KB
> 32bit tier1 only: (144 KB)        256 KB
> 32bit Xint: (11 KB) (b)     128 KB  
>
> CDS off:
>
> 64bit: (5,06 MB)       5.62 MB
> 64bit tier1 only:       (5,00 MB)       5,56 MB
> 64bit Xint: (4,84 MB)       5.44 MB
>
> 32bit     (3,69 MB)       3.75 MB
> 32bit tier1 only: (3,65 MB)       3.75 MB
> 32bit Xint: (3,52 MB)       3.62 MB
>
> Class space on/off
>
> CDS off, 64bit, +CompressedClassPointers: 5.44M
> CDS off, 64bit, -CompressedClassPointers: 5.38M
>
>
> _Notes:
> (a) Since JEP-387, with CDS=on, we pay very little committed footprint upfront (384K). For comparison, JDK 15 commits here 5.75M.
> (b) The seemingly high difference between Xint and C1+C2 - 11K vs 178K - is misleading: All initial classes get compiled, but since most of their metadata live in CDS, not in Metaspace, all we allocate at the start are MethodCounters. Hence, with -Xint, we almost allocate nothing. That changes as soon as we start loading application classes._
>
> Conclusions:
> - CDS=off increases metaspace footprint by a flat amount, in my case ~5MB, which makes sense.
> - Running with (any) compiler has not much influence once we start using Metaspace for real. The difference between C1-only and C1+C2 is neglectible, the difference between Xint and C1+C2 amounts to about 2% wrt to initial metaspace consumption.
> - Running with or without compressed Klass pointers makes not much difference. With class space, we pay for certain overhead twice, but at this early stage this is not noticeable.
> - The difference between 64bit and 32bit is more like 1.4-1.5, not the 1.3 factor we currently assume
>
> -----
>
> Proposal:
>
> 1) I propose to make MetaspaceSize independent from compiler. For one, if the intention was to have a lower threshold with compilers deactivated, that has never worked. E.g. on 64bit we always had a threshold of 20.75MB regardless of Xint/TieredStopAtLevel. Even if it worked, the compiler does not make that much difference in metaspace footprint.
>
> 2) I propose to slightly lower MetaspaceSize - on 32bit from 16M to 14M, on 64bit from 20.75M to 20M. This takes the slightly lower metaspace footprint since JEP 387 into account (less waste) and the scale I found to be higher than 1.3.
>
> This is all very cautious. For the standard VM, very little changes, so this is mainly a cleanup patch. We could probably tune MetaspaceSize down to much lower levels. And/or make size it differently depending on UseSharedSpaces. However, atm I don't have time to hunt regressions due to too early GCs.
>
> -----
>
> Tests: GA, nightlies at SAP

Looks good to me. I would suggest changing the RFE title to something like "Consolidate the default value of MetaspaceSize".

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2675
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8262074: Consolidate the default value of MetaspaceSize

Thomas Stuefe
On Tue, 23 Feb 2021 05:42:41 GMT, Ioi Lam <[hidden email]> wrote:

> Looks good to me.
Thanks!
> I would suggest changing the RFE title to something like "Consolidate the default value of MetaspaceSize".
Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2675
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8262074: Investigate defaults for MetaspaceSize

Stefan Karlsson
In reply to this post by Thomas Stuefe
Hi Thomas,

On 2021-02-23 06:31, Thomas Stuefe wrote:

> I was looking at whether the default values for MetaspaceSize (the initial threshold to start off a metaspace-motivated GC) still make sense after JEP-387.
>
> The default is dependent on compiler tier and bitness. It is also spread across all platforms.
>
> In addition to that, it also may get modified after Metaspace::ergo_initialize() in client-compiler-emulation-mode:
>
> https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/hotspot/share/compiler/compilerDefinitions.cpp#L194-L196
>
> which is unexpected and causes confusion (eg JDK-8261907, JDK-8261907).
>
> The reasons for this seem to originate from PermGen times:
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-February/045536.html
>
> ----
>
> Today, MetaspaceSize defaults to:
>
> - no compiler (eg Zero):      **4M** (32bit)   **5.19M** (64bit)
> - C1-only build:     **12M**
> - C1+C2 build (standard):    **16M** (32bit) **20,75M** (64bit)
>
> I was surprised to see that they do not depend on any compiler *runtime* switches. It only depends on build time decisions.
>
> ---
>
> How much do we use? I analyzed a simple java app to see the difference VM settings make on initial metaspace consumption. Committed space, used in brackets:
>
>
> (Note:                  (used)          committed
> CDS on:
>
> 64bit:       (181,58 KB)     384 KB  (a)
> 64bit tier1 only:       (170,04 KB)     384 KB
> 64bit Xint: (16,62 KB)      256 KB
>
> 32bit     (178 KB)        256 KB
> 32bit tier1 only: (144 KB)        256 KB
> 32bit Xint: (11 KB) (b)     128 KB
>
> CDS off:
>
> 64bit: (5,06 MB)       5.62 MB
> 64bit tier1 only:       (5,00 MB)       5,56 MB
> 64bit Xint: (4,84 MB)       5.44 MB
>
> 32bit     (3,69 MB)       3.75 MB
> 32bit tier1 only: (3,65 MB)       3.75 MB
> 32bit Xint: (3,52 MB)       3.62 MB
>
> Class space on/off
>
> CDS off, 64bit, +CompressedClassPointers: 5.44M
> CDS off, 64bit, -CompressedClassPointers: 5.38M
>
>
> _Notes:
> (a) Since JEP-387, with CDS=on, we pay very little committed footprint upfront (384K). For comparison, JDK 15 commits here 5.75M.
> (b) The seemingly high difference between Xint and C1+C2 - 11K vs 178K - is misleading: All initial classes get compiled, but since most of their metadata live in CDS, not in Metaspace, all we allocate at the start are MethodCounters. Hence, with -Xint, we almost allocate nothing. That changes as soon as we start loading application classes._
>
> Conclusions:
> - CDS=off increases metaspace footprint by a flat amount, in my case ~5MB, which makes sense.
> - Running with (any) compiler has not much influence once we start using Metaspace for real. The difference between C1-only and C1+C2 is neglectible, the difference between Xint and C1+C2 amounts to about 2% wrt to initial metaspace consumption.
> - Running with or without compressed Klass pointers makes not much difference. With class space, we pay for certain overhead twice, but at this early stage this is not noticeable.
> - The difference between 64bit and 32bit is more like 1.4-1.5, not the 1.3 factor we currently assume
>
> -----
>
> Proposal:
>
> 1) I propose to make MetaspaceSize independent from compiler. For one, if the intention was to have a lower threshold with compilers deactivated, that has never worked. E.g. on 64bit we always had a threshold of 20.75MB regardless of Xint/TieredStopAtLevel. Even if it worked, the compiler does not make that much difference in metaspace footprint.

I think it makes sense to get rid of this difference between build
configurations.

>
> 2) I propose to slightly lower MetaspaceSize - on 32bit from 16M to 14M, on 64bit from 20.75M to 20M. This takes the slightly lower metaspace footprint since JEP 387 into account (less waste) and the scale I found to be higher than 1.3.
>
> This is all very cautious. For the standard VM, very little changes, so this is mainly a cleanup patch. We could probably tune MetaspaceSize down to much lower levels. And/or make size it differently depending on UseSharedSpaces. However, atm I don't have time to hunt regressions due to too early GCs.

What would the motivation be for wanting to lower the size of
MetaspaceSize? I've gotten feedback from others reporting that we
trigger GCs too early, because of a (for them) too low MetaspaceSize.

Thanks,
StefanK

>
> -----
>
> Tests: GA, nightlies at SAP
>
> -------------
>
> Commit messages:
>   - Start
>
> Changes: https://git.openjdk.java.net/jdk/pull/2675/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2675&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8262074
>    Stats: 28 lines in 13 files changed: 0 ins; 27 del; 1 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/2675.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/2675/head:pull/2675
>
> PR: https://git.openjdk.java.net/jdk/pull/2675

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8262074: Consolidate the default value of MetaspaceSize [v2]

Thomas Stuefe
In reply to this post by Thomas Stuefe
> I was looking at whether the default values for MetaspaceSize (the initial threshold to start off a metaspace-motivated GC) still make sense after JEP-387.
>
> The default is dependent on compiler tier and bitness. It is also spread across all platforms.
>
> In addition to that, it also may get modified after Metaspace::ergo_initialize() in client-compiler-emulation-mode:
>
> https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/hotspot/share/compiler/compilerDefinitions.cpp#L194-L196
>
> which is unexpected and causes confusion (eg JDK-8261907, JDK-8261907).
>
> The reasons for this seem to originate from PermGen times:
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-February/045536.html
>
> ----
>
> Today, MetaspaceSize defaults to:
>
> - no compiler (eg Zero):      **4M** (32bit)   **5.19M** (64bit)
> - C1-only build:     **12M**
> - C1+C2 build (standard):    **16M** (32bit) **20,75M** (64bit)
>
> I was surprised to see that they do not depend on any compiler *runtime* switches. It only depends on build time decisions.
>
> ---
>
> How much do we use? I analyzed a simple java app to see the difference VM settings make on initial metaspace consumption. Committed space, used in brackets:
>
>
> (Note:                  (used)          committed
> CDS on:
>
> 64bit:       (181,58 KB)     384 KB  (a)
> 64bit tier1 only:       (170,04 KB)     384 KB
> 64bit Xint: (16,62 KB)      256 KB
>
> 32bit     (178 KB)        256 KB
> 32bit tier1 only: (144 KB)        256 KB
> 32bit Xint: (11 KB) (b)     128 KB  
>
> CDS off:
>
> 64bit: (5,06 MB)       5.62 MB
> 64bit tier1 only:       (5,00 MB)       5,56 MB
> 64bit Xint: (4,84 MB)       5.44 MB
>
> 32bit     (3,69 MB)       3.75 MB
> 32bit tier1 only: (3,65 MB)       3.75 MB
> 32bit Xint: (3,52 MB)       3.62 MB
>
> Class space on/off
>
> CDS off, 64bit, +CompressedClassPointers: 5.44M
> CDS off, 64bit, -CompressedClassPointers: 5.38M
>
>
> _Notes:
> (a) Since JEP-387, with CDS=on, we pay very little committed footprint upfront (384K). For comparison, JDK 15 commits here 5.75M.
> (b) The seemingly high difference between Xint and C1+C2 - 11K vs 178K - is misleading: All initial classes get compiled, but since most of their metadata live in CDS, not in Metaspace, all we allocate at the start are MethodCounters. Hence, with -Xint, we almost allocate nothing. That changes as soon as we start loading application classes._
>
> Conclusions:
> - CDS=off increases metaspace footprint by a flat amount, in my case ~5MB, which makes sense.
> - Running with (any) compiler has not much influence once we start using Metaspace for real. The difference between C1-only and C1+C2 is neglectible, the difference between Xint and C1+C2 amounts to about 2% wrt to initial metaspace consumption.
> - Running with or without compressed Klass pointers makes not much difference. With class space, we pay for certain overhead twice, but at this early stage this is not noticeable.
> - The difference between 64bit and 32bit is more like 1.4-1.5, not the 1.3 factor we currently assume
>
> -----
>
> Proposal:
>
> 1) I propose to make MetaspaceSize independent from compiler. For one, if the intention was to have a lower threshold with compilers deactivated, that has never worked. E.g. on 64bit we always had a threshold of 20.75MB regardless of Xint/TieredStopAtLevel. Even if it worked, the compiler does not make that much difference in metaspace footprint.
>
> 2) I propose to slightly lower MetaspaceSize - on 32bit from 16M to 14M, on 64bit from 20.75M to 20M. This takes the slightly lower metaspace footprint since JEP 387 into account (less waste) and the scale I found to be higher than 1.3.
>
> This is all very cautious. For the standard VM, very little changes, so this is mainly a cleanup patch. We could probably tune MetaspaceSize down to much lower levels. And/or make size it differently depending on UseSharedSpaces. However, atm I don't have time to hunt regressions due to too early GCs.
>
> -----
>
> Tests: GA, nightlies at SAP

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Increase MetaspaceSize default

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2675/files
  - new: https://git.openjdk.java.net/jdk/pull/2675/files/6b3c81ab..152ec617

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2675&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2675&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2675.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2675/head:pull/2675

PR: https://git.openjdk.java.net/jdk/pull/2675
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8262074: Consolidate the default value of MetaspaceSize [v2]

Thomas Stuefe
In reply to this post by Thomas Stuefe
On Tue, 23 Feb 2021 06:04:47 GMT, Thomas Stuefe <[hidden email]> wrote:

>> Looks good to me. I would suggest changing the RFE title to something like "Consolidate the default value of MetaspaceSize".
>
>> Looks good to me.
> Thanks!
>> I would suggest changing the RFE title to something like "Consolidate the default value of MetaspaceSize".
> Done.

> Hi Thomas,
>
(skip)

> > -----
> > Proposal:
> > 1) I propose to make MetaspaceSize independent from compiler. For one, if the intention was to have a lower threshold with compilers deactivated, that has never worked. E.g. on 64bit we always had a threshold of 20.75MB regardless of Xint/TieredStopAtLevel. Even if it worked, the compiler does not make that much difference in metaspace footprint.
>
> I think it makes sense to get rid of this difference between build
> configurations.
>
> > 2) I propose to slightly lower MetaspaceSize - on 32bit from 16M to 14M, on 64bit from 20.75M to 20M. This takes the slightly lower metaspace footprint since JEP 387 into account (less waste) and the scale I found to be higher than 1.3.
> > This is all very cautious. For the standard VM, very little changes, so this is mainly a cleanup patch. We could probably tune MetaspaceSize down to much lower levels. And/or make size it differently depending on UseSharedSpaces. However, atm I don't have time to hunt regressions due to too early GCs.
>
> What would the motivation be for wanting to lower the size of
> MetaspaceSize? I've gotten feedback from others reporting that we
> trigger GCs too early, because of a (for them) too low MetaspaceSize.

Initial metaspace usage is probably much lower than it was when these sizes were thought up. For one, due to the CDS, which is usually on. Then, due to the reduced waste in metaspace. See measurements. This may matter for low-consumption JVMs which do class unloading - since you would never hit the threshold, you may never clean up, unless the GC runs due to other reasons.

But I admit that I do not have a good base upon which to decide which size is right. Once could say "you must be able to load as many classes as you did when this limit was thought up" which would mean we could lower the limit much more aggressivly than I did. Or we could say "dont shake the boat" and leave the limits as they are. I tried to find a middle way.

However, it also makes sense to keep the limits as they are. Then this patch is truly just a cleanup.

I now set the 32bit limit to 16M, which is what we did have before; the 64bit threshold is set to 21M, which is 0.25M more than before, just to have a nice round number.

>
> Thanks,
> StefanK

Thanks, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/2675
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8262074: Consolidate the default value of MetaspaceSize [v2]

Coleen Phillimore-3
In reply to this post by Thomas Stuefe
On Tue, 23 Feb 2021 07:47:59 GMT, Thomas Stuefe <[hidden email]> wrote:

>> I was looking at whether the default values for MetaspaceSize (the initial threshold to start off a metaspace-motivated GC) still make sense after JEP-387.
>>
>> The default is dependent on compiler tier and bitness. It is also spread across all platforms.
>>
>> In addition to that, it also may get modified after Metaspace::ergo_initialize() in client-compiler-emulation-mode:
>>
>> https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/hotspot/share/compiler/compilerDefinitions.cpp#L194-L196
>>
>> which is unexpected and causes confusion (eg JDK-8261907, JDK-8261907).
>>
>> The reasons for this seem to originate from PermGen times:
>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-February/045536.html
>>
>> ----
>>
>> Today, MetaspaceSize defaults to:
>>
>> - no compiler (eg Zero):      **4M** (32bit)   **5.19M** (64bit)
>> - C1-only build:     **12M**
>> - C1+C2 build (standard):    **16M** (32bit) **20,75M** (64bit)
>>
>> I was surprised to see that they do not depend on any compiler *runtime* switches. It only depends on build time decisions.
>>
>> ---
>>
>> How much do we use? I analyzed a simple java app to see the difference VM settings make on initial metaspace consumption. Committed space, used in brackets:
>>
>>
>> (Note:                  (used)          committed
>> CDS on:
>>
>> 64bit:       (181,58 KB)     384 KB  (a)
>> 64bit tier1 only:       (170,04 KB)     384 KB
>> 64bit Xint: (16,62 KB)      256 KB
>>
>> 32bit     (178 KB)        256 KB
>> 32bit tier1 only: (144 KB)        256 KB
>> 32bit Xint: (11 KB) (b)     128 KB  
>>
>> CDS off:
>>
>> 64bit: (5,06 MB)       5.62 MB
>> 64bit tier1 only:       (5,00 MB)       5,56 MB
>> 64bit Xint: (4,84 MB)       5.44 MB
>>
>> 32bit     (3,69 MB)       3.75 MB
>> 32bit tier1 only: (3,65 MB)       3.75 MB
>> 32bit Xint: (3,52 MB)       3.62 MB
>>
>> Class space on/off
>>
>> CDS off, 64bit, +CompressedClassPointers: 5.44M
>> CDS off, 64bit, -CompressedClassPointers: 5.38M
>>
>>
>> _Notes:
>> (a) Since JEP-387, with CDS=on, we pay very little committed footprint upfront (384K). For comparison, JDK 15 commits here 5.75M.
>> (b) The seemingly high difference between Xint and C1+C2 - 11K vs 178K - is misleading: All initial classes get compiled, but since most of their metadata live in CDS, not in Metaspace, all we allocate at the start are MethodCounters. Hence, with -Xint, we almost allocate nothing. That changes as soon as we start loading application classes._
>>
>> Conclusions:
>> - CDS=off increases metaspace footprint by a flat amount, in my case ~5MB, which makes sense.
>> - Running with (any) compiler has not much influence once we start using Metaspace for real. The difference between C1-only and C1+C2 is neglectible, the difference between Xint and C1+C2 amounts to about 2% wrt to initial metaspace consumption.
>> - Running with or without compressed Klass pointers makes not much difference. With class space, we pay for certain overhead twice, but at this early stage this is not noticeable.
>> - The difference between 64bit and 32bit is more like 1.4-1.5, not the 1.3 factor we currently assume
>>
>> -----
>>
>> Proposal:
>>
>> 1) I propose to make MetaspaceSize independent from compiler. For one, if the intention was to have a lower threshold with compilers deactivated, that has never worked. E.g. on 64bit we always had a threshold of 20.75MB regardless of Xint/TieredStopAtLevel. Even if it worked, the compiler does not make that much difference in metaspace footprint.
>>
>> 2) I propose to slightly lower MetaspaceSize - on 32bit from 16M to 14M, on 64bit from 20.75M to 20M. This takes the slightly lower metaspace footprint since JEP 387 into account (less waste) and the scale I found to be higher than 1.3.
>>
>> This is all very cautious. For the standard VM, very little changes, so this is mainly a cleanup patch. We could probably tune MetaspaceSize down to much lower levels. And/or make size it differently depending on UseSharedSpaces. However, atm I don't have time to hunt regressions due to too early GCs.
>>
>> -----
>>
>> Tests: GA, nightlies at SAP
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>
>   Increase MetaspaceSize default

This looks good.  I appreciate the more conservative approach and doing this as a cleanup.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2675
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8262074: Consolidate the default value of MetaspaceSize [v2]

Thomas Stuefe
On Thu, 25 Feb 2021 23:38:11 GMT, Coleen Phillimore <[hidden email]> wrote:

> This looks good. I appreciate the more conservative approach and doing this as a cleanup.

Thank you Coleen!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2675
Reply | Threaded
Open this post in threaded view
|

Integrated: JDK-8262074: Consolidate the default value of MetaspaceSize

Thomas Stuefe
In reply to this post by Thomas Stuefe
On Mon, 22 Feb 2021 16:08:20 GMT, Thomas Stuefe <[hidden email]> wrote:

> I was looking at whether the default values for MetaspaceSize (the initial threshold to start off a metaspace-motivated GC) still make sense after JEP-387.
>
> The default is dependent on compiler tier and bitness. It is also spread across all platforms.
>
> In addition to that, it also may get modified after Metaspace::ergo_initialize() in client-compiler-emulation-mode:
>
> https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/hotspot/share/compiler/compilerDefinitions.cpp#L194-L196
>
> which is unexpected and causes confusion (eg JDK-8261907, JDK-8261907).
>
> The reasons for this seem to originate from PermGen times:
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2021-February/045536.html
>
> ----
>
> Today, MetaspaceSize defaults to:
>
> - no compiler (eg Zero):      **4M** (32bit)   **5.19M** (64bit)
> - C1-only build:     **12M**
> - C1+C2 build (standard):    **16M** (32bit) **20,75M** (64bit)
>
> I was surprised to see that they do not depend on any compiler *runtime* switches. It only depends on build time decisions.
>
> ---
>
> How much do we use? I analyzed a simple java app to see the difference VM settings make on initial metaspace consumption. Committed space, used in brackets:
>
>
> (Note:                  (used)          committed
> CDS on:
>
> 64bit:       (181,58 KB)     384 KB  (a)
> 64bit tier1 only:       (170,04 KB)     384 KB
> 64bit Xint: (16,62 KB)      256 KB
>
> 32bit     (178 KB)        256 KB
> 32bit tier1 only: (144 KB)        256 KB
> 32bit Xint: (11 KB) (b)     128 KB  
>
> CDS off:
>
> 64bit: (5,06 MB)       5.62 MB
> 64bit tier1 only:       (5,00 MB)       5,56 MB
> 64bit Xint: (4,84 MB)       5.44 MB
>
> 32bit     (3,69 MB)       3.75 MB
> 32bit tier1 only: (3,65 MB)       3.75 MB
> 32bit Xint: (3,52 MB)       3.62 MB
>
> Class space on/off
>
> CDS off, 64bit, +CompressedClassPointers: 5.44M
> CDS off, 64bit, -CompressedClassPointers: 5.38M
>
>
> _Notes:
> (a) Since JEP-387, with CDS=on, we pay very little committed footprint upfront (384K). For comparison, JDK 15 commits here 5.75M.
> (b) The seemingly high difference between Xint and C1+C2 - 11K vs 178K - is misleading: All initial classes get compiled, but since most of their metadata live in CDS, not in Metaspace, all we allocate at the start are MethodCounters. Hence, with -Xint, we almost allocate nothing. That changes as soon as we start loading application classes._
>
> Conclusions:
> - CDS=off increases metaspace footprint by a flat amount, in my case ~5MB, which makes sense.
> - Running with (any) compiler has not much influence once we start using Metaspace for real. The difference between C1-only and C1+C2 is neglectible, the difference between Xint and C1+C2 amounts to about 2% wrt to initial metaspace consumption.
> - Running with or without compressed Klass pointers makes not much difference. With class space, we pay for certain overhead twice, but at this early stage this is not noticeable.
> - The difference between 64bit and 32bit is more like 1.4-1.5, not the 1.3 factor we currently assume
>
> -----
>
> Proposal:
>
> 1) I propose to make MetaspaceSize independent from compiler. For one, if the intention was to have a lower threshold with compilers deactivated, that has never worked. E.g. on 64bit we always had a threshold of 20.75MB regardless of Xint/TieredStopAtLevel. Even if it worked, the compiler does not make that much difference in metaspace footprint.
>
> 2) I propose to slightly lower MetaspaceSize - on 32bit from 16M to 14M, on 64bit from 20.75M to 20M. This takes the slightly lower metaspace footprint since JEP 387 into account (less waste) and the scale I found to be higher than 1.3.
>
> This is all very cautious. For the standard VM, very little changes, so this is mainly a cleanup patch. We could probably tune MetaspaceSize down to much lower levels. And/or make size it differently depending on UseSharedSpaces. However, atm I don't have time to hunt regressions due to too early GCs.
>
> -----
>
> Tests: GA, nightlies at SAP

This pull request has now been integrated.

Changeset: c9e91897
Author:    Thomas Stuefe <[hidden email]>
URL:       https://git.openjdk.java.net/jdk/commit/c9e91897
Stats:     28 lines in 13 files changed: 0 ins; 27 del; 1 mod

8262074: Consolidate the default value of MetaspaceSize

Reviewed-by: iklam, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/2675