-
Enhancement
-
Resolution: Fixed
-
P4
-
25
-
b06
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8368659 | 25.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | master |
Noticed this while working on a related bug (JDK-8359960):
First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, and I think that is related, the benchmark is really, really noisy.
First, I see the benchmark executes a single shot per fork. As such, I believe the benchmark really tests the cost of initial GC, that probably drags a lot of (potentially non-benchmark-related) objects through new (possibly awkwardly wired, despite +AlwaysPreTouch) memory. The first iteration is 80 ms/op for me here, and the second one is -- whoosh -- only 3 ms/op! Second, and I think that is related, the benchmark is really, really noisy.
- backported by
-
JDK-8368659 Stabilize SystemGC benchmarks
-
- Resolved
-
- caused by
-
-
- Resolved
-
- relates to
-
JDK-8343047 G1: FullGC marking time of large object array unstable between builds
-
- Open
-
-
-
- Closed
-
- links to
-
Commit(master)
openjdk/jdk25u/503ba0a9
-
Commit(master)
openjdk/jdk/a9bd1ad4
-
Review(master)
openjdk/jdk25u/237
-
Review(master)
openjdk/jdk/26182
(3 links to)