We are getting OOMs occasionally. These seems to happen for many (if not all) our various builds on our project, but not consistently for any of them. Each of these builds is run with a -Xmx of 256m. An example stack trace is given below. It seems related to caching of task archives, and my .bin file is ~30 MB right now. I think (but might be wrong) that this file is cached in memory (with other Java overhead), meaning that a lot of memory might be used by this cache. Do you guys think this is a potential problem area, or should I be looking elsewhere? I need to get this addressed as the build is not very reliable right now (it fails this way ~20% of the time).
java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1838) at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1747) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1161) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.gradle.cache.DefaultSerializer.write(DefaultSerializer.java:31) at org.gradle.cache.btree.BTreePersistentIndexedCache$DataBlock.setValue(BTreePersistentIndexedCache.java:625) at org.gradle.cache.btree.BTreePersistentIndexedCache$DataBlock.useNewValue(BTreePersistentIndexedCache.java:660) at org.gradle.cache.btree.BTreePersistentIndexedCache.put(BTreePersistentIndexedCache.java:137) at org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.update(DefaultTaskArtifactStateRepository.java:330) at org.gradle.api.internal.changedetection.ShortCircuitTaskArtifactStateRepository$1.update(ShortCircuitTaskArtifactStateRepository.java:38) at org.gradle.api.internal.project.taskfactory.ExecutionShortCircuitTaskExecuter.execute(ExecutionShortCircuitTaskExecuter.java:50) at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:57) at org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:35) at org.gradle.api.internal.tasks.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:32) at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:226) at org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:167) at org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:160) at org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:78) at org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBuildExecuter.java:161) at org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.java:54) at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:180) at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:115) at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:82) at org.gradle.launcher.Main.execute(Main.java:93) at org.gradle.launcher.Main.main(Main.java:42) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.gradle.launcher.GradleMain.main(GradleMain.java:54) P.S. It looks like default serialization is used for much of this data, leading to a bloated .bin file. I zipped it and got ~4.7 MB for the same file, and looking into the .bin file shows lots of repeated information. First, the class names of the serialized objects get repeated a lot. Secondly, the pathing for the input/output files are the same so much of that is also redundant. This might not be related to the OOMs, but it seemed interesting. -- John Murph Automated Logic Research Team
