Consider dropping -Xmx2048m (and -Xms256m) from eclipse.ini

[guw]

Today's JVM is really good at managing memory. They even strive a balance to not consume all available host memory but leave room for other applications. Thus, a setting for min/max is usually not needed anymore.

Especially the setting for max (-Xmx) is harmful because it limits the ability of Eclipse to open larger workspaces. The user experience is bad because Eclipse then fails with an out of memory error even though the machine has plenty of memory available.

Other tools (VS Code with the JDT Java Language Server) have a prompt, which would modify the eclipse.ini file automatically to increase the memory. However, Eclipse does not. Besides, modifying the file is considered a security breach on some operating systems (eg., Mac OS) and then the OS may prevent Eclipse from starting.

[merks]

Are there any links to back up this assertion? What is the maximum heap size when none is specified? Why would others prompt when that’s not really necessary?

[guw]

The default these days is one quarter of the available memory (1/4).

java -XX:+PrintFlagsFinal -version 2>&1 | grep "MaxHeapSize"

This has been the behavior since at least 17 (if not 11).

However, your comment made me read more on the topic and I found an interesting discussion: adoptium/adoptium-support#35

Thus, it looks like there are lower default when the client VM is used.

Interestingly, the Equinox launcher has been updated to prefer the server JVM.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553538

It looks like the question became more complicated than just removing it. Sigh.

Why would others prompt when that’s not really necessary?

I don't know. Especially since the VS Code extension I mentioned as an example includes its own JRE and is in full control this is confusing.

[guw]

This could be better options:

-XX:InitialRAMPercentage
-XX:MaxRAMPercentage
-XX:MinRAMPercentage

Source:
https://stackoverflow.com/a/57895677/275347

[merks]

I think all the justj jres bundled with the products use the server vm. My computer has 128g of memory so 1/4 is rather huge! 😱

[nitind]

I can see value in having a start size that serves as a reasonable minimum. Less so the max value.

[jonahgraham]

I am open to such changes - it may be most appropriate for different EPPs to have different initial/max sizes. AFAIK we have traditionally tracked/coordinated with the SDK allocation arguments

The last updates for EPP was done in e8f1046 and the matching change in platform SDK was eclipse-platform/eclipse.platform.releng.aggregator@48208e7

Note that allowing too big of an Xmx (e.g. 25% of Ed's 128g) leads to Eclipse looking like it is very memory intensive even though much of it the occupied memory is garbage.

Other tools (VS Code with the JDT Java Language Server) have a prompt, which would modify the eclipse.ini file

I am very keen on this idea. p2 updates modify eclipse.ini already and there are other breaks of the macOS signing (see Bug 573309 and Bug 494293) which is currently being researched as part of this Eclipse IDE WG funded dev effort so if this approach is interesting I recommend reaching out to see if any proposals from that funded dev effort covers this situation.

[jonahgraham]

Any final thoughts on this? If we want to try a change for 2023-09 having something for M3 would be good.

PRs welcome.

[grandinj]

I logged eclipse-platform/eclipse.platform.releng.aggregator#1463

I suggest that we simply leave out the XmX parameter, and allow the VM to work with the machine as best it can.

I note that the user experience is much worse than simply throwing an OOM - instead, various things like my debugger would randomly start misbehaving and locking up.

[jonahgraham]

We should make this change for 2025-03 M1 - I requested feedback on the issue that @grandinj filed too eclipse-platform/eclipse.platform.releng.aggregator#1463 (comment)