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

[Aleksey Shipilev]

On Thu, 21 Nov 2024 23:26:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

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

Yes, I don't want to emit something that looks like a heap usage GC log line, if it is not. Unfortunately, `X->Y (Z) T.TTTTms` is a common format for X and Y as heap use. I agree posting X == Y would be only marginally better. So, maybe this goes as middle ground:


Concurrent uncommit XXXXM (YYYYM) z.zzzms


...where XXXX is the amount uncommitted, YYYY is the final heap capacity?

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

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