Zero based Coops now 30GB

[Thomas Stüfe]

Hi Ecki,

On Sat, Mar 29, 2025 at 1:23 AM ecki <ecki at zusammenkunft.net> wrote:

> Hello,
>
> I just noticed (from -Xlog:gc+init=info) that in later Java versions the
> limit for Zero based coops mode seems to be increased from 26GB to 30GB (in
> my case Windows x64 with Zulu21),
>
Did I miss discussion and announcement about it, how different are
> platforms/versions/distributions/configurations in this? (32bit mode seems
> to have also increased to 2020MB limit),
>
>
There is no hard-coded limit for zero-based compression. Instead, it is
derived from object alignment (LogMinObjAlignmentInBytes) since we use the
oop alignment to increase the zero-based range.

At startup, we try to fit the heap into the zero-based range; that may work
or not, depending on address space population.

We did some changes, however, to how CDS and class space are placed. We
earmarked some space in lower address regions in older JDKs for that. We
don't do that anymore, at least not by default; CDS/class space is now
always relocated for unrelated reasons. A side effect is that we have more
space available in lower address regions, and therefore, we can fit larger
heaps in there. That side effect is also beneficial, since oop compression
is more important than class pointer compression.

Also with zero based being now 30GB and compressed limit at 31, there is a
> very narrow range for non zero based compression, was it discussed to
> remove it or extend the limit to larger sizes automatically with more
> overhead modes?
>
>
No! That is not desirable. The chance of low-address heap placement is
high, but not guaranteed, since it depends on address space population
(factors like ASLR etc). One example, the JVM may be embedded into a custom
launcher and may be loaded and initialized late. It could therefore face an
already very fragmented address space. The JVM must still be able to cope
with these scenarios.

In these cases, it is still much better to use non-zero-based compressed
oops instead of switching off oop compression.

Switching off oop compression would make memory footprint of a JVM a lot
more unpredictable: if the heap happens to fit the heap into low address
regions, JVM would use X amount of GB, but if not (semi-random), it would
use X * 1.5 (or whatever the factor for that app is resulting from
uncompressed oops).

Cheers, Thomas



> Gruß,
> Bernd
> --
> https://bernd.eckenfels.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250329/72af1c59/attachment-0001.htm>