java.lang.OutofMemoryError:Java heap space error running gradle build

[Jay Seletz]

I have a pipeline running gradle builds.  The pipeline is using docker and mysql for services as well as several caches.  The pipeline is intermittently running out of java heap space.  I'm trying to understand the memory usage/limitations as described here.

When it says "The build container is given 1024 MB of the total memory", is that a hard limit, unaffected by the "size: 2x" setting?  If the gradle build step needs to use more than 1gb, what are my options?

It sounds like the 4 or 8GB made available to the pipeline is total memory for the build container plus other docker containers run as services and any DockerInDocker commands - I'm trying to understand how much of that 4/8 GB can be allocated to my Gradle step e.g.:

pipelines:
  default:
    - step:
        script:
          - ./gradlew build sonarqube

Update: I am also setting jvm args for gradle in the gradle.properties, e.g.

org.gradle.jvmargs=-Xmx2048m

[sreepathy]

As we know, generally, the Java heap space error actually indicates that your JVM is running out of memory to allocate for objects in the heap. Which means, the Java Virtual Machine (JVM) running is actually running out of memory allocated to the Java heap. There are a few common reasons which may cause this issue, like applications may utilize more memory than what we have allocated. Even though you have already increased the JVM options this type of issue may come up if the application is holding on to objects longer than necessary. And other reasons could be there might be memory leaks happening since unused objects may not be released properly or the default heap size may be smaller for the workload the machine handles.

This error java.lang.OutOfMemoryError: Java heap space during your Gradle build occurs because the JVM inside your build container requires more memory. It is requesting more memory than the container limit that is already set. By default, the build container is capped at 1 GB.  This is actually a hard limit unless you configure the step with a larger size. 

You can set size using the parameter org.gradle.jvmargs=-Xmx. By doing so you are actually instructing your JVM to use up to specified GB of heap. Suppose, if the step only has 1 GB available, then the container cannot meet that request and an OOM occurs. To resolve this, you can try increasing the step size, so Gradle gets more memory. It also helps to tune your JVM arguments so that the heap uses only about 50–60% of the container memory, leaving room for other overheads like Metaspace and threads. Along with this, when you keep reviewing Gradle parallelism settings it will actually reduce the memory pressure. Using fewer workers or disabling parallel builds may help. Another option is that you can split the pipeline into smaller steps, which avoids large memory spikes in a single build.

If you need more heap space,  it's good that you should increase the step size or also you can try adjusting your JVM settings to stay within the available memory.

To learn more interesting details about the OutOfMemoryError: Java heap space error, You can check out this blog How to Solve OutOfMemoryError: Java heap space. This will give you more insights about this Java Heap Space error.

[Steven Vaccarella]

Hi Jay,

Yes, the 4GB (or 8GB for 2x steps) is the total memory available for your step and is split up between your build container and any services you configure. By default each service gets 1GB, so if you configure 3 services in a 1x step your build container will only have 1GB available. At the other extreme, if you don't configure any services in a 2x step your build container will get the full 8GB. You can also change the amount of memory assigned to each service, which will affect the amount of memory left over for your build container.