RFR: JDK-8267562: G1: Missing BOT in Open Archive regions causes long pauses

[Thomas Schatzl]

On Mon, 31 May 2021 04:09:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Populate G1BlockOffsetTableParts and associated G1BlockOffsetTable::_offset_array entries for 'open' archive regions during VM initialization at runtime.
> 
> G1BlockOffsetTable divides the covered space (Java heap) into “N”-word subregions (“N” is from 2^”LogN”). It uses an _offset_array to tell how far back it must go to find the start of a block that contains the first word of a subregion. Every G1 region (is a G1ContiguousSpace) owns a G1BlockOffsetTablePart (associates to part of the _offset_array), which covers space of the current region. For a mapped open archive heap region with pre-populated Java objects, its G1BlockOffsetTablePart is never setup at runtime because there is no allocation done within the region. As a result, G1BlockOffsetTablePart::block_start() always does lookup from the start (bottom) of an open archive region when called at runtime, regardless if the given 'addr' is near the bottom, top or in the middle of the region. The lookup becomes linear, instead of O(2^LogN). Large heap region size makes the situation worse and young-gen pauses longer.
> 
> Removed G1FullGCPrepareTask::G1CalculatePointersClosure::update_bot (introduced by JDK-8264987 change, https://github.com/openjdk/jdk/pull/3459). It's merged as G1BlockOffsetTablePart::update, which is used for Survivor-turned-to-Old regions in full gc and open archive region. Thanks Thomas Schatzl  for pointing to JDK-8264987 change for code reuse.
> 
> Tested with tier1 and hotspot_gc tests on linux_x86. Appreciate any help for testing other platforms and more tiers. Thanks!

Lgtm apart from the comment issue.

src/hotspot/share/cds/filemap.cpp line 2053:

> 2051:     // Populate the open archive regions' G1BlockOffsetTableParts. That ensures
> 2052:     // fast G1BlockOffsetTablePart::block_start operations for a given address
> 2053:     // within the open archive regions during G1RemSet::refine_card_concurrently.

Not only refinement is subject to the issue but any operation trying to find start of an object (e.g. card table scanning). Please fix the comment accordingly.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4265