JEP 278: Additional Tests for Humongous Objects in G1

AuthorKirill Zhaldybin
OwnerIgor Ignatyev
Created2015/10/19 14:12
Updated2017/04/10 04:22
TypeFeature
StatusClosed / Delivered
Componenthotspot / gc
ScopeImplementation
Discussionhotspot dash gc dash dev at openjdk dot java dot net
EffortS
DurationM
Priority3
Reviewed byAleksandre Iline, Jon Masamitsu, Mikael Vidstedt
Endorsed byMikael Vidstedt
Release9
Issue8139889

Summary

Develop additional white-box tests for the Humongous Objects feature of the G1 Garbage Collector.

Non-Goals

We will not develop tests for G1 Eager Reclamation.

Description

Garbage First (G1) is a generational garbage collector which divides the heap into equal-sized regions. It has a concurrent collection phase, which can work in parallel with the application, and is multi-threaded.

G1 treats objects bigger than one-half of a memory region, called humongous objects, differently than other objects:

Since G1 is a concurrent and multi-threaded GC, it makes black-box testing very difficult. Several ways to collect dead objects, a few concurrent threads, the ability to work in parallel with the running application, and generally complex algorithms make it nearly impossible to figure out G1's internal state. To address these issues we will extend the WhiteBox API and implement Java tests that use this API to check G1's internal state. We will also be able to reuse these newly developed WhiteBox API methods in stress tests.

To test that the code which handles humongous objects works as expected we need G1 to provide more details about the internal representation of humongous objects on the heap. We will add additional debug methods to G1 which will allow us to get information from its internal data structures and provide control over the initiation of garbage collection. The latter is important because there are three code paths which can collect unreachable humongous objects: A full garbage collection, concurrent marking and young GC in case of G1 Eager Reclamation. To test each path we need to avoid the other.

To help with this we will extend the WhiteBox API with:

Alternatives

Possible alternatives are:

Risks and Assumptions

New tests may require changes in G1. This could impact the performance and stability of G1, though we think that is unlikely. If G1 is negatively affected then we could build product binaries without debug methods.