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.
