-
Bug
-
Resolution: Fixed
-
P4
-
9
-
b74
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8135598 | emb-9 | Sangheon Kim | P4 | Resolved | Fixed | team |
When calculating the size of the next PLAB we pass along the current number of gc workers, calculating an "optimal" PLAB size for that number of gc workers, that is fed directly to the desired PLAB size predictor.
When the number of workers changes dynamically (with -XX:+UseDynamicNumberOfGCThreads), the desired PLAB size value returned is still tuned to the number of threads that has been used previously, losing performance.
A better solution would be to feed the PLAB size predictor the value for a single thread, and calculate the actual desired size according to the current number of threads instead.
When the number of workers changes dynamically (with -XX:+UseDynamicNumberOfGCThreads), the desired PLAB size value returned is still tuned to the number of threads that has been used previously, losing performance.
A better solution would be to feed the PLAB size predictor the value for a single thread, and calculate the actual desired size according to the current number of threads instead.
- backported by
-
JDK-8135598 REDO - Determining the desired PLAB size adjusts to the the number of threads at the wrong place
-
- Resolved
-
- clones
-
-
- Closed
-
- relates to
-
-
- Resolved
-
-
JDK-8030849 Investigate high fragmentation/waste in some situations during allocation during GC in G1
-
- Open
-
-
-
- Resolved
-
There are no Sub-Tasks for this issue.