RFR: 8312023: Parallel pretouch should shortcut when only 1 thread is needed [v2]

Aleksey Shipilev shade at openjdk.org
Mon Dec 4 10:41:39 UTC 2023


On Fri, 1 Dec 2023 00:44:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> There may have been some concern that some task might care about the kind of thread it runs on?
>> 
>> Exactly, in generic case you don't know if caller thread is set up to do the task in the way the worker threads are. This pretouching code is one of the cases where we know running in caller is fine. Existing code even does it when no worker pool is available.
>>  
>>> So I'm not convinced this change should be made.
>> 
>> I believe we want to do it. Round-tripping to worker pool is asking for a latency hiccup. Even if things go well, we lose double-digit microseconds on this path. This is a common optimization we do. Last time [we did it in safepoints](https://bugs.openjdk.org/browse/JDK-8306738) with [great results](https://github.com/openjdk/jdk/pull/13616#issuecomment-1538206572).
>
>> > There may have been some concern that some task might care about the kind of thread it runs on?
>> 
>> Exactly, in generic case you don't know if caller thread is set up to do the task in the way the worker threads are. This pretouching code is one of the cases where we know running in caller is fine. Existing code even does it when no worker pool is available.
> 
> That's easily dealt with.  Provide a configuration mechanism (a boolean argument for run_task or a variant of
> run_task with a different name) that controls whether running on the current thread is permitted and defaults
> to no.  Then let clients opt in to that feature.  In my opinion that's a lot better than having each client that can
> run on the current thread provide an ad hoc implementation for doing so.

> I concur with @kimbarrett: although being guilty of accepting such changes, there has been an effort in the past to _remove_ the per-caller `task.work(0)` for the reason that it just adds lots of code duplication, with the goal of eventually providing a way to have any client interested opt in without code duplication. Please add a way to have clients opt in for any task as Kim suggests.

All right, that would be [JDK-8321242](https://bugs.openjdk.org/browse/JDK-8321242) and #16945. I'll leave this PR to actually flip the switch for pretouch tasks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16882#issuecomment-1838271079


More information about the hotspot-gc-dev mailing list