groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: travis-ci changes
Date Tue, 24 Oct 2017 11:31:56 GMT
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 <forax@univ-mlv.fr> 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 <
> blackdrag@gmx.org> 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.
>

Mime
View raw message