tstuefe

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/compiler/compilationMemoryStatistic.cpp:956), pid=333549, tid=333575
#  fatal error: c2 (1210) org/springframework/boot/loader/jar/Handler::openConnection((Ljava/net/URL;)Ljava/net/URLConnection;): Hit MemLimit - limit: 41943040 now: 42945328
#
# JRE version: OpenJDK Runtime Environment VENDORVENDOR (25.0) (fastdebug build 25-internal-adhoc.thomas.source)
# Java VM: OpenJDK 64-Bit Server VM VENDORVENDOR (fastdebug 25-internal-adhoc.thomas.source, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /shared/projects/openjdk/jdk-jdk/output-fastdebug/core.333549)
#

tstuefe

330342:
Compiler Memory Statistic
    Method              : java/net/URL::openConnection(()Ljava/net/URLConnection;)
    Compiler            : c2
    Arena Usage at peak : 58817816 (56,09M)
    Nodes at peak       : 19239
    Compile ID          : 1214
    Result              : ok
    Thread              : 0x00007f4f341e64c0
    Timestamp           : 1,673

tstuefe

--- a/test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
+++ b/test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java
@@ -38,7 +38,6 @@
  * @summary Test Loading of default archives in all configurations (requires --enable-cds-archive-coh)
  * @requires vm.cds
  * @requires vm.bits == 64
- * @requires !vm.gc.ZGenerational
  * @library /test/lib
  * @modules java.base/jdk.internal.misc
  *          java.management

tstuefe

diff --git a/src/hotspot/share/memory/classLoaderMetaspace.cpp b/src/hotspot/share/memory/classLoaderMetaspace.cpp
index 3315c15e677..20b501cc52a 100644
--- a/src/hotspot/share/memory/classLoaderMetaspace.cpp
+++ b/src/hotspot/share/memory/classLoaderMetaspace.cpp
@@ -130,8 +130,9 @@ MetaWord* ClassLoaderMetaspace::expand_and_allocate(size_t word_size, Metaspace:
 
 // Prematurely returns a metaspace allocation to the _block_freelists
 // because it is not needed anymore.
-void ClassLoaderMetaspace::deallocate(MetaWord* ptr, size_t word_size, bool is_class) {
+void ClassLoaderMetaspace::deallocate(MetaWord* ptr, size_t word_size) {

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

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

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

commit 60dc9adee66e6f83ccb406a965e61c49e2541d28
Author: tstuefe <[email protected]>
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

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

```
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)