Set the vmArg HeapDumpOnOutOfMemoryError to be optional

[licam]

Expected Behavior

Do not write heap dump files in case the user doesn't wants it. The user can disable this by a setting.

Current Behavior

The extension adds '-XX:+HeapDumpOnOutOfMemoryError' automatically:
https://github.com/spring-projects/sts4/blob/main/vscode-extensions/vscode-spring-boot/lib/Main.ts#L43
On cases where our users get OOM, their file system is blowing up with the hprof files. Can this be disabled by a setting? It can be set to true by default, and when a user wish to not have this files he can choose to disable it.

Context
We will use -XX:HeapDumpPath to write the files to some temp folder. But we need to be able to not have it written at all, as was on older versions of this extension. As our IDE is on cloud with shared resources it's problematic once this huge files are generated and blows up the disk.

[martinlippert]

Absolutely agree @licam , this default setting it still there from the early days and should be removed. In case of debugging OOM situations, users can add this back via the preferences.

[martinlippert]

Beyond that: if you are encouraging OOM situations with the language server process (sounds like you do), it would be extremely interesting to share some details here (maybe even one of those generated heap dumps) to debug this situation and see why you are running into the OOM situation.

[licam]

Thank you for the prompt response. We have a certain case where there's a huge Java project and the users gets OOM all the time from the extension. For our best understanding, that's because of the size of the project. Unfortunately we do not have the project either as it's a customer's project and they are not allowed to share. Regarding the heap dump, I'm verifying it.

[martinlippert]

You could also add -Xmx2048m as a JVM arg to the preferences for the JVM that is used to run the language server in order to avoid the OOM situation as well. But nevertheless, it would be extremely interesting to analyze the OOM situation in more detail for us.

[licam]

Thanks. We are aware of that, but as the resources are shared between the cloud users, increasing the heap size might have a negative effect on other users.

[martinlippert]

Understand. One additional argument to dive deeper here and analyze the root cause of the OOM and fix that... :-)

[BoykoAlex]

Fixed with 01a69ba

[martinlippert]

@licam I still would love to get a few more details about this OOM and try to find the root cause for this. Can you provide insights into:

• how large is the project? how many java source files (roughly)?
• if you enable the log output of the Spring Boot language server to be written to a file (you can define a file in the preferences), could you paste the OOM stack trace that shows up there and maybe a few additional lines above that exception (or - if possible - the full log file)?

I would like to investigate this in more detail to see if we can avoid the OOM altogether and make the tooling work smoothly even if you have those large projects and limited memory settings for the tooling and the language server process.

Very much hope that you can share those details.