I tried numerous settings without luck on the travis container infrastructure which has a 4G memory limit. So I switched to the fully-virtualized infra instead (sudo: required) which has 7.5G mem allocated and we have no problems. We'll have to stick to that for now.
Cheers, Paul. On Tue, Oct 24, 2017 at 9:31 PM, Paul King <[email protected]> wrote: > 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. >> > >
