Because this measurement is not as granular as previously, and because uncommitting memory is something we want to do conservatively, as a response to low memory utilization,
The actual implementation in
* Missing wait, the uncommitting is not actually spread out, but happens all at once.
* Reactivity, if the process starts using memory that was below the previous watermark, uncommitting should stop.
* Structure, the current implementation has a lot of different dependencies and has state spread out over multiple classes. Refactor to keep the logic contained to the ZUncommitter, and provide better named facilitating functions on the ZPartition and ZMappedCache. And make the lifecycle of ZUncommitter more explicit.
* Events, overhaul the JFR uncommit events to be sent (and track the time for) a chunk of uncommits without any waits.
An alternative discussed has been to do uncommitting based on GC triggers rather than a periodically. So rather than using ZUncommitDelay, we could have our proactive GCs actually trigger and track uncommitting. This might be a future RFE, but it was not attempted here as it would change user facing APIs. JDK-8329758 will more than likely overhaul the uncommit triggers as well, and the whole concept of ZUncommitDelay and having to tune how to uncommit will go away.
- links to
-
Review(master) openjdk/jdk/25198