[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Integrated: 8318706: Implement JEP 423: Region Pinning for G1
From:       Thomas Schatzl <tschatzl () openjdk ! org>
Date:       2023-11-29 10:06:30
Message-ID: U-tvwflAl_EZslenz0gGaCfAfDQ2jMzlD7V3cr_mMY0=.520c2c72-b046-4180-8a08-8aa94d87fdcf () github ! com
[Download RAW message or body]

On Tue, 24 Oct 2023 09:56:57 GMT, Thomas Schatzl <tschatzl@openjdk.org> wrote:

> The JEP covers the idea very well, so I'm only covering some implementation details \
> here: 
> * regions get a "pin count" (reference count). As long as it is non-zero, we \
> conservatively never reclaim that region even if there is no reference in there. \
> JNI code might have references to it. 
> * the JNI spec only requires us to provide pinning support for typeArrays, nothing \
> else. This implementation uses this in various ways: 
> * when evacuating from a pinned region, we evacuate everything live but the \
> typeArrays to get more empty regions to clean up later. 
> * when formatting dead space within pinned regions we use filler objects. Pinned \
> regions may be referenced by JNI code only, so we can't overwrite contents of any \
> dead typeArray either. These dead but referenced typeArrays luckily have the same \
> header size of our filler objects, so we can use their headers for our fillers. The \
> problem is that previously there has been that restriction that filler objects are \
> half a region size at most, so we can end up with the need for placing a filler \
> object header inside a typeArray. The code could be clever and handle this \
> situation by splitting the to be filled area so that this can't happen, but the \
> solution taken here is allowing filler arrays to cover a whole region. They are not \
> referenced by Java code anyway, so there is no harm in doing so (i.e. gc code never \
> touches them anyway). 
> * G1 currently only ever actually evacuates young pinned regions. Old pinned \
> regions of any kind are never put into the collection set and automatically \
> skipped. However assuming that the pinning is of short length, we put them into the \
> candidates when we can. 
> * there is the problem that if an applications pins a region for a long time g1 \
> will skip evacuating that region over and over. that may lead to issues with the \
> current policy in marking regions (only exit mixed phase when there are no marking \
> candidates) and just waste of processing time (when the candidate stays in the \
> retained candidates) 
> The cop-out chosen here is to "age out" the regions from the candidates and wait \
> until the next marking happens. 
> I.e. pinned marking candidates are immediately moved to retained candidates, and if \
> in total the region has been pinned for `G1NumCollectionsKeepUnreclaimable` \
> collections it is dropped from the candidates. Its current value is fairly random. 
> * G1 pauses got a new tag if there were pinned regions in the collection set. I.e. \
> in addition to something like: 
> `GC(6) P...

This pull request has now been integrated.

Changeset: 38cfb220
Author:    Thomas Schatzl <tschatzl@openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38cfb220ddadbb401cc15f313aadb8234f626210
                
Stats:     1823 lines in 59 files changed: 1150 ins; 435 del; 238 mod

8318706: Implement JEP 423: Region Pinning for G1

Reviewed-by: ayang, iwalulya, sjohanss

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

PR: https://git.openjdk.org/jdk/pull/16342


[prev in list] [next in list] [prev in thread] [next in thread]