-
Enhancement
-
Resolution: Fixed
-
P4
-
25
-
b06
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.
- caused by
-
-
- Resolved
-
- relates to
-
JDK-8343047 G1: FullGC marking time of large object array unstable between builds
-
- Open
-
-
-
- Open
-
- links to
-
Commit(master)
openjdk/jdk/a9bd1ad4
-
Review(master)
openjdk/jdk/26182