-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tuning JVM options for throughput #2797
Conversation
One more comment about the choice of GC; the Scala compiler team noted performance regressions when moving to Java 9 due to the default GC changing from the ParallelGC (a throughput collector) to the GC1C (a response-time collector). |
Codecov Report
@@ Coverage Diff @@
## master #2797 +/- ##
==========================================
- Coverage 94.28% 94.26% -0.02%
==========================================
Files 367 367
Lines 6926 6927 +1
Branches 297 297
==========================================
Hits 6530 6530
- Misses 396 397 +1 Continue to review full report at Codecov.
|
EDIT: I'm looking at the wrong times in travis... The first build took ~30min, which is consistent with other recent successful builds Going to close and reopen to give it another go and see how consistent it is |
Second build took ~31min On that basis I'm not sure this is going to yield any improvement in build times, but it may be less likely that builds will freeze on account of memory usage |
Thanks so much! @DavidGregory084, I am not an expert on concurrent CMS collector v.s. parallel GC, but I vote that we give it a try. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, I need to try these options too!
Changes the JVM options used by SBT somewhat.
Here is the reasoning for each change:
-Xmx4G
- the Travis infrastructure that we're using has 7.5GB of memory, this could probably be increased further if forking tests was also disabledXX:-UseGCOverheadLimit
- I think that this is just creating zombie builds that are stuck thrashing the GC and will timeout anyway due to lack of progress, better to fail early IMO-XX:+CMSClassUnloadingEnabled
- this is relevant only for the CMS collector-XX:+UseConcMarkSweepGC
to-XX:+UseParallelGC
- from what I understand the concurrent CMS collector is a response time collector, whereas the parallel GC is a throughput collector (more on this in the Oracle docs), which is much more relevant for compiling code IMOHere is some VisualVM output from running
sbt clean test/clean catsJS/test
, which normally stalls for me locally with the default options.Before:
Note that I had to kill this build as it got stuck.
After:
Hopefully this will translate to improvements on Travis too! Who knows!