On Mon, 22 Feb 2021 13:36:00 GMT, Pavel Rappo <pra...@openjdk.org> wrote:

>> This change is on the right track.
>> 
>> 1. Although I'm not sure how "utilization" translates to a similar 
>> measurement obtained through a profiling tool, I do think we can use 
>> "utilization" as a rough estimate.
>> 
>> FWIW, on my machine the base "utilization" for JDK codebase is 13%. After I 
>> have moved the initialization of the `start` timestamp from the creation of 
>> the writer closer to the submission of the first task, "utilization" 
>> increased to 17%.
>> 
>> I'd recommend computing elapsed times using `java.lang.System.nanoTime`. 
>> Using `nanoTime` avoids some hazards of using `currentTimeMillis` for such 
>> purposes.
>> 
>> 2. The `--background-writer` option is processed **after** the writer has 
>> been created. To see the "utilization" numbers I had to tweak the change and 
>> rebuild the project.
>
> To add to my earlier comment 
> https://github.com/openjdk/jdk/pull/2665#discussion_r580185985.
> 
> I reread the `ExecutorService` API to refresh my memory. It looks like there 
> is **NO** happens-before edge between "actions taken by a task" and 
> "awaitTermination returned true" . So, to read that `taskBusy` value safely 
> we have to do something else.

Here's some more thoughts. I tweaked this change to see when the thread that 
submits tasks cannot immediately acquire a permit. Using that tweaked change I 
built documentation for JDK for various number of queued tasks (QUEUED_TASKS). 
That allowed me to collect the following statistics:


| queue, n | attempts, n | failed, n | utilization, % |
| -------- | ----------- | --------- | -------------- |
|        0 |       14789 |      3346 |             19 |
|        5 |           " |       348 |             20 |
|       10 |           " |       120 |             20 |
|       15 |           " |        30 |             20 |
|       20 |           " |        10 |             19 |
|      100 |           " |         0 |             19 |

1. Either I'm misinterpreting these results or the original premises (1) "we 
currently consume (execute) tasks faster than we produce them" and (2) "A 
semaphore is used to throttle the number of requests, although in practice this 
rarely takes effect, because it is quicker to write documents than to generate 
them" do not hold on my machine. In particular, when QUEUED_TASKS == 0, the 
task-submitting thread fails to immediately acquire a permit in a quarter of 
attempts.
2. Note that "utilization" doesn't change even though the `ExecutorService` 
always has tasks to execute. That raises a question of how to interpret 
"utilization".

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

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

Reply via email to