For jdk6-8 we use these settings: org.gradle.jvmargs=-Xmx1G -XX:MaxPermSize=384m -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled For jdk9 we currently have:
org.gradle.jvmargs=-ea -Xmx1G Recommendations on what to use instead greatly appreciated. On Tue, Oct 24, 2017 at 8:20 PM, Remi Forax <[email protected]> wrote: > Maybe it's because if you do not specify a GC, the default GC is not the > same between 8 and 9 (CMS vs G1) > > G1 tends to consume more memory because it delays the collection to avoid > long pause. > > Rémi > > > > On October 24, 2017 8:02:10 AM GMT+02:00, Jochen Theodorou < > [email protected]> wrote: >> >> On 23.10.2017 14:14, Paul King wrote: >> [...] >> >>> They all run fine for me locally but currently the oraclejdk9 builds are >>> bombing out on the CI server during the generateGrammarSource task (the >>> Antlr plugin): >>> >>> https://travis-ci.org/apache/groovy/builds/291471224 >>> >> >> what I see there is: >> >> Caused by: org.gradle.process.internal.ExecException: Process 'Gradle ANTLR >> Worker 2' finished with non-zero exit value 137 >>> >>> at >>> org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:369) >>> >>> at >>> org.gradle.process.internal.worker.DefaultWorkerProcess.waitForStop(DefaultWorkerProcess.java:190) >>> >>> at >>> org.gradle.process.internal.worker.DefaultWorkerProcessBuilder$MemoryRequestingWorkerProcess.waitForStop(DefaultWorkerProcessBuilder.java:228) >>> >>> at >>> org.gradle.process.internal.worker.DefaultSingleRequestWorkerProcessBuilder$1.invoke(DefaultSingleRequestWorkerProcessBuilder.java:118) >>> >>> ... 91 more >>> >>> BUILD FAILED >>> >>> Total time: 1 mins 52.505 secs >>> >>> Publishing build information... >>> >>> https://gradle.com/s/apqc2iu7ft74u >>> >>> Stopped 1 worker daemon(s). >>> >>> Received result Failure[value=org.gradle.initialization.ReportedException: >>> org.gradle.internal.exceptions.LocationAwareException: Execution failed for >>> task ':generateGrammarSource'.] from daemon DaemonInfo{pid=3192, >>> address=[5320ada0-f54f-43d7-a69c-0a6ac21b7748 port:41001, >>> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Busy, >>> lastBusy=1508754740834, >>> context=DefaultDaemonContext[uid=2cf5e2d2-f46d-4d2e-b63d-ccd36263ed46,javaHome=/usr/lib/jvm/java-9-oracle,daemonRegistryDir=/home/travis/.gradle/daemon,pid=3192,idleTimeout=120000,daemonOpts=-Xmx1G,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant,-ea]} >>> (build should be done). >>> >> >> And that means to me we have a worker that fails and no real hint as of >> how the worker daemon failed. >> >> If anyone has any thoughts on why, I'd be keen to hear from you or >>> confirmation on which environments it works/doesn't work. >>> >> >> According to >> https://stackoverflow.com/questions/38967991/why-are-my-gradle-builds-dying-with-exit-code-137 >> it could be a OOME. Then it would be travis killing the daemon because >> it consumes too much memory. >> >> There are a handful of places where a test or part of a test that is >>> broken on jdk9 is currently skipped over (normally has FIX_JDK9 in a >>> comment nearby). We obviously want to get rid of all of those before >>> final releases of 2_6 or 3_0 but at least with a green build now on jdk9 >>> we should be able to stop any new errors being added to the list. Happy >>> for any help getting rid of any of the FIX_JDK9 hacks. >>> >> >> I have to take a look what these are >> >> bye Jochen >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >
