.mvn/jvm.config: Use more memory

[sratz]

No description provided.

[github-actions]

Test Results

 1 758 files  +  160   1 758 suites  +160   1h 32m 2s ⏱️ + 1m 32s
 4 173 tests ±    0   4 150 ✅ ±    0   23 💤 ±0  0 ❌ ±0 
13 119 runs  +1 121  12 952 ✅ +1 120  167 💤 +1  0 ❌ ±0 

Results for commit e20a305. ± Comparison against base commit 9e339b2.

[sratz]

@laeubi This fixed the github-action-based matrix build on Windows / macOS, but now the Jenkins build appear to crash (probably due to exceeding memory). Do you have an idea how we can control the memory more specifically for the individual jobs/checks?

[HannesWell]

but now the Jenkins build appear to crash (probably due to exceeding memory). Do you have an idea how we can control the memory more specifically for the individual jobs/checks?

Yes the kubernetes agent went out of memory, which is indicated, but the somewhat cryptic message (i.e. some-number killed) :
/home/jenkins/agent/workspace/eclipse.platform_master@tmp/durable-5a80a481/script.sh.copy: line 2: 151 Killed mvn clean verify --batch-mode ...

Do you have an idea how we can control the memory more specifically for the individual jobs/checks?

You could use the MAVEN_OPTS environment variable instead and set (or not set it) it to different values in different jobs/pipelines, like it's for example done for the releng.aggregator Jenkins build.
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/f3dc2460b731a00cfcf8d9648c78f330fa4c95a4/Jenkinsfile#L16

For GH workflows you can also set specific environment variables using the following syntax:
https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#env

Of course one could also increase the memory only a little bit more and not just double it.

In general I'm not fully convinced in general that the .mvn/jvm.config file is the right place to specify any JVM memory limits, as the requirements can greatly vary depending on the executed build configuration and the execution environment. The current settings affects all builds, even local ones on machines with much more RAM than the average build-runner.
So my suggestion is to remove that setting from .mvn/jvm.config and set the MAVEN_OPTS environment variable in those jobs for which the default is not sufficient.

[merks]

Yes this looks quite different from what we did in the aggregator repository. But I think it runs with an 8g pod not a 4g pod.

[HannesWell]

But I think it runs with an 8g pod not a 4g pod.

Yes it does. But since the Jenkins build ran fine before I think it would be a waste of resources to use a larger pod there just to have more RAM for the build at GH runners. :/
But as described in my previous message, I generally think that memory settings in the .mvn/jvm.config are generally the wrong tool for the job.

[sratz]

:(

So we would have to parameterize the re-usable job in the aggregator repo somehow?

[laeubi]

btw that the reason why I previously used a percentage of memory to use (defaults to 1/4), maintaining fixed values of RAM is always getting the wrong number sooner or later.

[sratz]

btw that the reason why I previously used a percentage of memory to use (defaults to 1/4), maintaining fixed values of RAM is always getting the wrong number sooner or later.

Hmm, before this PR it was set to -Xmx1500m.