Native Image Committer and Community Meeting 2024-05-02

[christianwimmer]

List of all past and upcoming meetings: #3933

New and Noteworthy

• Layered native images:
  [GR-53704] Persist Layer Typecheck Info. #8864
  [GR-53508] Refactor cross layer calls and link base layer .so. #8845
  [GR-51606] Introduce a typeReached check for Class.forName. #8335
  [GR-52945] Introduce layered image singleton. #8819
  [GR-52911] Patch base layer objects offsets. #8810
  [GR-52265] Extend layered images support. #8794
  [GR-49965] [GR-51573] [GR-52422] Persist and reload analysis universe and shadow heap #8744

• Special exceptions for missing configurations:
  [GR-47365] Integrate proxy registration to the reflection config #8822
  [GR-49770] Use Glob Patterns In Resource Config File #8715

• Usability:
  [GR-52578] Dump All Registered Resources #8676
  [GR-43837] Enable --report-unsupported-elements-at-runtime by default and deprecate the option. #8815

• Image size
  [GR-52534] Change digest algorithm and encoding. #8772
  [GR-52732] Optimize stack trace information for implicit exceptions. #8675
  [GR-53449] Do not register all declared methods of service provider classes for reflection. #8840
  [GR-46564] Support more than one image CodeInfo and reduce frame info redundancy with global method ids. #8753

• Compatibility
  [GR-53803] Only allow Unsafe.allocateInstance for types registered explicitly in the configuration. #8869 Tightening the rules which classes can be allocated with Unsafe.allocateInstance.
  [GR-52885] Recompute Buffer.address field for array-based buffers in the image heap. #8826

• Monitoring / tools:
  Add Java-level JFR event tests and annotate JfrAdaptiveSampler methods with BasedOnJDKFile #8542
  Change CSV format of call tree report #8774
  [GR-52454] [GR-53085] Add exit handlers if JFR or NMT are enabled. #8710

Deep Dive: Mark&Compact GC

#8870 adds a mark&compact GC for the old generation of the Serial GC. The primary intention is to reduce worst-case memory usage compared to the copying GC, which can use 2x the current heap size when all objects survive.

Typical mark&compact collectors do four passes over the heap to:

• mark live objects
• assign new locations to them
• update their references for the new locations
• move them to their new locations

New locations are often stored in each individual object. This would significantly enlarge our current 4/8-byte object headers and add memory overhead even outside of GC. Using side tables would require this memory only during GC (and could also collect with fewer passes), but it requires allocating these tables precisely when memory can be scarce.

Our implementation uses the object header as it is and stores new locations of contiguous sequences of surviving objects in records in the gaps between them (made up of dead objects). In order to find an object's new location when updating a reference to it, we first identify the referenced object's aligned chunk. In the chunk's card table, we temporarily keep an index, which we use to find a record near the object. The records also form a singly-linked list, which we can follow further to find the exact record that applies to the object. With this record, we can then compute the object's new location and update references accordingly.

When encountering a chunk with pinned objects, we sweep the gaps in them instead. Unfortunately, we cannot fill them with other surviving objects because our design requires that the order of objects stays the same (or records would be overwritten prematurely). Currently we also copy only entire object sequences and not split them to fit smaller areas of unused memory at the end of chunks (but does not seem to be an issue in practice). We also still copy objects which have an identity hash code that is based on their current address and needs to be stored in an additional field, enlarging the objects.

The performance of the mark&compact GC is currently somewhat comparable to the current copying GC, sometimes better and sometimes worse, both in terms of CPU usage and memory usage. Depending on the application's heap usage, complete collections can become more expensive, which can cause the GC policy to use more memory to need fewer collections.

The initial implementation also isn't heavily tuned, so there should still be room for improvement. For example, the object order is currently determined by the copying collector in the young generation which often places related objects apart from each other. The GC policy can likely also be tweaked for the different characteristics.

Points of interest in the implementation:

• option CompactingOldGen in SerialGCOptions
• subclass CompactingOldGeneration of the now abstract OldGeneration class
• classes in package com.oracle.svm.core.genscavenge.compacting
• object header bits in ObjectHeaderImpl
• checks for SerialGCOptions.useCompactingOldGen() in several places

This work is based on a prototype by JKU student Christian Aistleitner for his master's thesis.