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

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8318706: Implementation of JDK-8276094: JEP 423: Region Pinning for G1 [v5]
From:       Thomas Schatzl <tschatzl () openjdk ! org>
Date:       2023-10-31 19:14:13
Message-ID: OJvSZuaSMvnWjiinsPTKAuAJrOPJeAmem8u6IgLhWHw=.c853a76e-7dcf-4c77-b07d-874d2126cc41 () github ! com
[Download RAW message or body]

> 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...

Thomas Schatzl has updated the pull request incrementally with one additional commit \
since the last revision:

  Fix compilation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16342/files
  - new: https://git.openjdk.org/jdk/pull/16342/files/78cb9df0..e5dfbb73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16342&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16342&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16342/head:pull/16342

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


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