RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3]

Stefan Johansson sjohanss at openjdk.org
Tue Sep 27 17:03:11 UTC 2022


On Tue, 27 Sep 2022 15:33:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I think this is fine as is, we want updates to the current state and predictions too (also currently looking at logs). Maybe there is need for more detailed (trace-level?) logging though, still unsure.
>
> The current cards, predicted cards, and predicted time until GC are, I think, all interesting here.  The point is to give some indication of what the controller is doing and why.  (The activation/deactivation messages are probably less interesting now, but that's why I demoted them to trace level.)  For looking at what's going on with refinement `-Xlog:gc+refine*=debug` is now the thing to use.  I wouldn't want to demote the above to trace level, and only logging on changes to wanted wouldn't provide that additional detail that I found useful in making sure things were working properly.

I agree that the other numbers are interesting, even if there is no change. Maybe the initial message could be altered depending on if we are going to update the number of threads. Or be more generic, something like:

[20,057s][debug][gc,refine      ] Concurrent refinement: wanted threads: 0, cards: 79767, predicted: 79767, time: 0,00ms

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

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


More information about the hotspot-dev mailing list