Details
-
Enhancement
-
Resolution: Unresolved
-
P4
-
20
Description
Running BigRamTester with 8g heap
java -Xms8g -Xmx8g -XX:+UseG1GC -XX:ParallelGCThreads=6 -Xlog:gc,gc+phases=debug:old_1.gc.log::filecount=0 BigRAMTester.java
shows very bad scaling wrt to cards scanned/ms; actually with 6 threads the number of cards scanned/ms is twice the number with e.g. 18 threads (total gc time is still much better at 18 threads).
E.g. with 6 threads cards scanned/ms ranges from 2.5k to 3k/ms, while with 18 threads it ranges from 1k to 1.5k, see the attached figure (the "6t" run is with -XX:ParallelGCThreads=6, the other with 18).
Investigate why this is the case and potentially find improvements.
Changing the card scan chunk size did not change anything.
Note that BRT has a very low card/reference ratio, so that might impact the numbers somehow.
java -Xms8g -Xmx8g -XX:+UseG1GC -XX:ParallelGCThreads=6 -Xlog:gc,gc+phases=debug:old_1.gc.log::filecount=0 BigRAMTester.java
shows very bad scaling wrt to cards scanned/ms; actually with 6 threads the number of cards scanned/ms is twice the number with e.g. 18 threads (total gc time is still much better at 18 threads).
E.g. with 6 threads cards scanned/ms ranges from 2.5k to 3k/ms, while with 18 threads it ranges from 1k to 1.5k, see the attached figure (the "6t" run is with -XX:ParallelGCThreads=6, the other with 18).
Investigate why this is the case and potentially find improvements.
Changing the card scan chunk size did not change anything.
Note that BRT has a very low card/reference ratio, so that might impact the numbers somehow.
