tstuefe

```
0x0000000000000001 0000000000000000000000000000000000000000000000000000000000000001 (size=64, length=1, rotation=0)
0x0000000000000002 0000000000000000000000000000000000000000000000000000000000000010 (size=64, length=1, rotation=1)
0x0000000000000003 0000000000000000000000000000000000000000000000000000000000000011 (size=64, length=2, rotation=0)
0x0000000000000004 0000000000000000000000000000000000000000000000000000000000000100 (size=64, length=1, rotation=2)
0x0000000000000006 0000000000000000000000000000000000000000000000000000000000000110 (size=64, length=2, rotation=1)
0x0000000000000007 0000000000000000000000000000000000000000000000000000000000000111 (size=64, length=3, rotation=0)
0x0000000000000008 0000000000000000000000000000000000000000000000000000000000001000 (size=64, length=1, rotation=3)
0x000000000000000c 0000000000000000000000000000000000000000000000000000000000001100 (size=64, length=2, rotation=2)

tstuefe

Today's compressed class pointers encode a 64-bit pointer into 32 bits. Introduced with JDK 8, compressed class pointers first depended on compressed object pointers; with JDK 15, this dependency was removed (JDK-8241825). Enabling compressed class pointers is highly desirable. Today, only two reasons remain that require an application to disable compressed class pointers:

• It uses JVMCI, which on some platforms inhibits the use of compressed class pointers.
• It loads more than roughly three million classes. This limit is imposed by the way class space is implemented today. Note that the latter limit is theoretical - an application that hits this limit would use approximately six to ~30 GB for metaspace alone; we have yet to find an application that does.

Compact object headers will limit the bits available to identify a class to 32 bits or less. The feature, therefore, requires compressed class pointers to be enabled unconditionally. The cases mentioned abo

tstuefe

commit 60dc9adee66e6f83ccb406a965e61c49e2541d28
Author: tstuefe <thomas.stuefe@gmail.com>
Date:   Wed Jul 19 14:29:12 2023 +0200

    remove TLS stuff

diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp
index 9f357d8e6b0..3dd44c1e0d2 100644
--- a/src/hotspot/os/linux/os_linux.cpp
+++ b/src/hotspot/os/linux/os_linux.cpp

tstuefe

Proposal for an alternative memory tracker for virtual memory that is faster and simpler.

Preface

Regions as sequence of addresses

Stop treating and storing regions as regions. That causes a lot of redundancy (end pointer of one region is the start of another) and ambiguity.

Instead, lets treat regions as sequence of annotated pointers:

tstuefe

Keybase proof

I hereby claim:

• I am tstuefe on github.
• I am tstuefe (https://keybase.io/tstuefe) on keybase.
• I have a public key ASAK2RZL4sMn4SawJ1qKxfG3eqw1MaKlrXz3k33gs08KZAo

To claim this, I am signing this object:

tstuefe

Background

We store class information in Klass, and resolving Klass from oop is a hot path. One example is GC: During GCs, we churn through tons of objects and need to get at least object size (layout helper) and Oopmap from Klass frequently. Therefore, the way we resolve an nKlass matters for performance.

Today (non-Lilliput), we go from Object to Klass (with compressed class pointers) this way: We pluck the nKlass from the word adjacent to the MW. We then calculate Klass* from nKlass by - typically - just adding the encoding base as immediate. We may or may not omit that add, and we may or may not shift the nKlass, but the most typical case (CDS enabled) is just the addition.

Today's decoding does not need a single memory access, it can happen in registers only.

In Lilliput, the nKlass lives in the MW (which allows us to load nKlass with the same load that loads the MW). Therefore, nKlass needs to shrink. The problem with the classic 32-bit nKlass is that its value range is not used effectively. Klas