RFR: 8254758: Change G1ServiceThread to be task based [v4]

[Thomas Schatzl]

On Tue, 27 Oct 2020 07:54:10 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1ServiceThread.cpp line 283:
>> 
>>> 281:   task->execute();
>>> 282: 
>>> 283:   double duration = os::elapsedVTime() - start;
>> 
>> use of elapsedVTime() seems wrong here and above as I would only care about wall time between executions.
>
> For walltime **between** executions you will have to enable `gc+task+start` to get the start time of tasks and look in the log how long it was between two executions (or have the specific task log this). This is measuring the time it took to execute a task, the reason I use vTime is because a task can join the suspendible thread set, and because of this be waiting for a big part of the execution. Using vTime will then show how much the task really used.
> 
> If it should be allowed that a task wait for a GC to complete could of course be changed, and then using wall clock time would work.

I think this is confusing wrt to all other similar messages. All other concurrent tasks print wall time from start to end. Also for periodicity control (i.e. did it start and end on time) wall time is typically more interesting.

While it is interesting to know how much cpu resources a task took (and for noticing when your machine is overloaded), it is much more interesting to know when it started and ended in absolute terms to see that it was on time or not. I understand that you can derive this yourselves, but this seems tiresome.

Maybe print both similar to "time" output showing both real time and cpu time? I.e. something like

"G1 Service Thread (%s) %1.3fms (cpu: %1.3fms)", task->name(), ...."

(fwiw I think the existing use of elapsedVTime particularly for limiting marking step length in g1 is wrong)

While we are at logging, JFR logging for the tasks would be interesting  for these tasks too. Could you file a new CR for that?

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

PR: https://git.openjdk.java.net/jdk/pull/734