RFR: 8342444: Shenandoah: Uncommit regions from a separate, STS aware thread [v7]

[William Kemper]

On Thu, 21 Nov 2024 08:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yes, I spent some time trying to resurrect `ShenandoahConcurrentPhase` for uncommit here, but it really doesn't want to be used outside of a gc cycle. Also, previously it was logging heap _usage_, which isn't quite what we want here (this may actually increase during this phase, which makes it seem as though nothing is being uncommitted).
>> 
>> I've restored the original logging format, but instead of logging heap usage it is now logging heap committed before and after. Here is an excerpt from specjbb2015 with `-Xms5g -Xmx10g`:
>> 
>> 
>> [2024-11-20T20:02:25.056+0000][97.396s][22293][info][gc,start       ] Concurrent uncommit
>> [2024-11-20T20:02:25.072+0000][97.412s][22293][info][gc             ] Concurrent uncommit 5424M->5120M(5120M) 15.988ms
>> [2024-11-20T20:05:17.916+0000][270.255s][22293][info][gc,start       ] Concurrent uncommit
>> [2024-11-20T20:05:18.169+0000][270.508s][22293][info][gc             ] Concurrent uncommit 10240M->5120M(5120M) 253.048ms
>> [2024-11-20T20:06:45.329+0000][357.668s][22293][info][gc,start       ] Concurrent uncommit
>> [2024-11-20T20:06:45.596+0000][357.935s][22293][info][gc             ] Concurrent uncommit 10240M->5120M(5120M) 267.144ms
>> [2024-11-20T20:06:57.147+0000][369.486s][22293][info][gc,start       ] Concurrent uncommit
>> [2024-11-20T20:06:57.148+0000][369.487s][22293][info][gc             ] Concurrent uncommit 5456M->5440M(5440M) 1.189ms
>
> If we are emitting a log line that looks like a properly formatted GC log line, but the numbers there mean something else for `Concurrent uncommit`, we are bound to confuse users and automatic tools. Uncommit should affect `capacity`, this is how we know how deep we have uncommitted. So, I suggest we emit:
> 
> 
> Concurrent uncommit XXXXM->XXXXM (YYYYM) z.zzzms
> 
> 
> ...where `XXXX` is the heap used at the end of uncommit (note before and after are the same) and YYYY is capacity. This will not expose users to thinking uncommit grows the heap usage, and would give us instantaneous view on heap usage and capacity.

Hmm, the numbers are preceded by `Concurrent uncommit`, with that context it's not much of a stretch to think these numbers represent the change in _committed_ memory. The original log message (in which heap usage may increase during uncommit) was _not_ helpful. A message with the same format in which heap usage also appears to _not change at all_ during an uncommit is also perplexing. Are we trying too hard to preserve the original, not useful message? Maybe we just want a new message that plainly says: 


Concurrently uncommitted XXXXM in z.zzzms

or

Concurrent uncommit: time z.zzzms, committed before XXXXM, committed after YYYYM, capacity ZZZZM

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22019#discussion_r1853077616