Groovy upgrade crashing due to heap size

Technical Discussion
1

When upgrading moqui with the newer groovy version, I’m getting a heap crash [2]. It seems that the root cause might be coming from GROOVY-12318. The suspicison is that under the default heap size of 512MB the parser cache cleanup happens too late.

The solution is either A) upgrade groovy, or B) to add to framework/build.gradle the below snippet [1]. Upgrading groovy causes other issues, so the faster workaround for now is to apply below snippet [1].

FYI @jonesde @michael

[1]

tasks.withType(GroovyCompile).configureEach {
    groovyOptions.forkOptions.memoryMaximumSize = '1g'
}

[2]

❯ ./gradlew build

> Task :framework:compileStartJava
Note: /home/taher/Desktop/moqui-framework/framework/src/start/java/MoquiStart.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

> Task :framework:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

> Task :framework:compileGroovy FAILED

[Incubating] Problems report is available at: file:///home/taher/Desktop/moqui-framework/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':framework:compileGroovy'.
> Java heap space

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to generate a Build Scan (powered by Develocity).
> Get more help at https://help.gradle.org.

BUILD FAILED in 1m
3 actionable tasks: 3 executed
2

I tried every version after 5.0.3 (the previous used version), and I had the same issue, failed compileGroovy due to heap memory on every version unless I bumped the memory to 1gb.

I also noticed that the time more than doubled for all of them

| Groovy | Worker | Wall | CPU  |
|--------|--------|------|------|
| 5.0.3  | 512m   | 27s  | 1m18 |
| 5.0.4  | 1g     | 64s  | 2m39 |
| 5.0.5  | 1g     | 62s  | 2m33 |
| 5.0.8  | 1g     | 54s  | 2m29 |
| 5.1.1  | 1g     | 55s  | 2m31 |
| 5.1.2  | 1g     | 54s  | 2m29 |
3

Yeah then possibly a different reason or root cause. We should adopt the workaround until we figure out what’s going on.

4

That is odd, I haven’t run into that locally and I’m wondering what the difference is. I’m using OpenJDK 21.0.12, the embedded Gradle 9.2.0, and I haven’t looked into it, but if it is doing system stats based max heap it may matter that my current dev machine has 64GB RAM, and it is a desktop running Ubuntu.

Is this with OOTB moqui-framework or are there any additions or changes?

The workaround of specifying a larger heap size seems a reasonable workaround, and not likely a big deal with 512M vs 1G… it does make me wonder why it is failing on some systems and not others.

5

It’s perhaps what you said, the JVM allocates based on underlying machine specs.

On further investigation it seems like the issue might come from @CompileStatic compiler changes that are more heavy in memory. Suffice to say we faced this in multiple machines to make this workaround worth it until we figure out why groovy got that issue recently. My machine has 32GB ram and still faces this so not a small machine. It could be something also that depends on the instruction set! Without deeper digging it’s hard to tell.

I should also add I’m on openjdk 21 and embedded gradle

6

I also faced a similar issue. I updated build.gradle with the following configuration:

tasks.withType(GroovyCompile).configureEach {
    groovyOptions.fork = true
    groovyOptions.forkOptions.memoryMaximumSize = '1g'
}

Note

forkOptions only takes effect when fork is set to true.

7

@deepak I think the fork flag is not necessary, this seems to be purely a memory pressure issue.