2

For JVM after Java 8

  1. When the size of metaspace > -XX:metaspaceSize, it will trigger a gc.
  2. No matter how you configure -XX:metaspaceSize and -XX:maxMetaspaceSize, the initial size of metaspace is usually a fixed value (20.8M) on a 64-bit server.
  3. The JVM will resize metaspace automatically when it reaches close to the current capacity.
  4. Then, if -XX:metaspaceSize is 20G for example, the current size of the metaspace is 18M and a large number of new objects (about 100M) must be allocated, the JVM must resize the metaspace for these new objects, will JVM triggers a full GC before resizing?
ProtossShuttle
  • 1,623
  • 20
  • 40
  • 1
    No, metaspace resizing not trigger Full GC. JVM will resize metaspace after trigger GC. – Turac Jul 24 '19 at 08:05
  • 1
    There seems to be a weird mindset when you consider “growing” and “resizing” to be different things like with “*when the metaspace is to grow up from 18M to 40M …, the JVM must resize the metaspace*”, as the growth from 18M to 40M is not the reason for a resize, but the result of it. – Holger Jul 24 '19 at 12:04
  • @Holger sorry that i didn't make it clear – ProtossShuttle Jul 25 '19 at 02:22
  • You have this back to front. GC runs when space is low, and resizing is a possible *result* of that. Not a cause. – user207421 Jul 25 '19 at 03:25

2 Answers2

4

First of all, "the size of the metaspace" is ambiguous, and thus meaningless without the context. There are at least five metrics: reserved, committed, capacity and used memory as described in this answer, and the high-water mark, also known as capacity_until_gc.

Metaspace layout

Metaspace is not just one contiguous region of memory, so it does not resize in the common sense. Instead, when allocation happens, one or more of the above metrics changes.

  1. On the fastest path a block of metadata is allocated from the current chunk. used memory increases in this case, and that's it.
  2. If there is not enough room in the current chunk, JVM searches for a possibly free existing chunk. If it succeeds in reusing chunks, capacity increases. No GC happens until this point.
  3. If there are no free chunks, JVM tries to commit more memory, unless the new committed size would exceed capacity_until_gc.
  4. If capacity_until_gc threshold is reached, JVM triggers a GC cycle.
  5. If GC does not free enough memory, the high-water mark is increased so that another Virtual Space will be allocated.

After GC, the high-water mark value is adjusted basing on the following JVM flags:

  • -XX:MinMetaspaceFreeRatio (used to calculate how much free space is desirable in the metaspace capacity to decide how much to increase the HWM);
  • -XX:MaxMetaspaceFreeRatio (used to decide how much free space is desirable in the metaspace capacity before decreasing the HWM);
  • -XX:MinMetaspaceExpansion (the minimum expansion of Metaspace in bytes);
  • -XX:MaxMetaspaceExpansion (the maximum expansion of Metaspace without full GC).

TL;DR It's not that simple. JVM can definitely commit more Metaspace memory without triggering GC. However, when HWM is reached, GC is triggered and HWM is recomputed according to the ergonomics policy.

apangin
  • 92,924
  • 10
  • 193
  • 247
2

You can configure metaspace size but JVM can increase or decreased size by depended platform. See Oracle docs.

-XX:MetaspaceSize=size

Sets the size of the allocated class metadata space that will trigger a garbage collection the first time it is exceeded. This threshold for a garbage collection is increased or decreased depending on the amount of metadata used. The default size depends on the platform.

Community
  • 1
  • 1
Turac
  • 667
  • 1
  • 4
  • 19