-
Enhancement
-
Resolution: Unresolved
-
P4
-
17, 21, 22
Related to JDK-8312021, but a point fix for JDK-8252221.
In `MutableSpace::initialize`, we call these two:
```
if (AlwaysPreTouch) {
PretouchTask::pretouch("ParallelGC PreTouch head", (char*)head.start(), (char*)head.end(),
page_size, pretouch_workers);
PretouchTask::pretouch("ParallelGC PreTouch tail", (char*)tail.start(), (char*)tail.end(),
page_size, pretouch_workers);
}
```
...which start the pre-touch threads unconditionally, even when we only need one thread anyway. This incurs latency of about 100us (2x 50us) in my setups. We can run the pre-touch the in the caller thread, like it was done beforeJDK-8252221 to eliminate that overhead.
In `MutableSpace::initialize`, we call these two:
```
if (AlwaysPreTouch) {
PretouchTask::pretouch("ParallelGC PreTouch head", (char*)head.start(), (char*)head.end(),
page_size, pretouch_workers);
PretouchTask::pretouch("ParallelGC PreTouch tail", (char*)tail.start(), (char*)tail.end(),
page_size, pretouch_workers);
}
```
...which start the pre-touch threads unconditionally, even when we only need one thread anyway. This incurs latency of about 100us (2x 50us) in my setups. We can run the pre-touch the in the caller thread, like it was done before
- relates to
-
JDK-8312021 Parallel GC pre-touches memory unnecessarily when space boundaries move
- Open
-
JDK-8252221 Use multiple workers for Parallel GC pre-touching
- Resolved
- links to
-
Review openjdk/jdk/16882