OutOfMemoryError after editing a file with custom XML schema for a while

[fefrei]

For me, this extension regularly runs into OOM errors.

I'm editing a moderately-sized XML file (1​​ 500 lines, 130 KB) that uses a custom XML schema (of about 300 lines). This works well, and I receive proper IntelliSense suggestions and schema violation errors, until, after some amount of editing, the extension seems to run inte an OutOfMemory error:

[Info  - 11:02:51] May 28, 2021 11:02:51 org.eclipse.lemminx.XMLLanguageServer initialize()
Message: Initializing XML Language server
LemMinX Server info:
 - Version : 0.16.2
 - Java : C:\Program Files\OpenJDK\jdk-16.0.1
 - VM Version : 16.0.1
 - Git 544a8d4 - [maven-release-plugin] prepare release 0.16.2
[Info  - 11:02:51] May 28, 2021 11:02:51 org.eclipse.lemminx.extensions.contentmodel.uriresolver.XMLCatalogResolverExtension setCatalogs()
Message: Adding XML catalog './some-folder/catalog.xml' with expand system id 'file:///c%3A/Users/fefrei/git/my-project/some-folder/catalog.xml' and root URI 'file:///c%3A/Users/fefrei/git/my-project/'.
[Info  - 11:31:05] May 28, 2021 11:31:05 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Info  - 11:39:52] May 28, 2021 11:39:52 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Info  - 11:39:52] May 28, 2021 11:39:52 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Info  - 11:39:52] May 28, 2021 11:39:52 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Info  - 11:39:52] May 28, 2021 11:39:52 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Warn  - 12:23:36] May 28, 2021 12:23:36 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 326
[Warn  - 13:34:08] May 28, 2021 01:34:08 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 500
[Warn  - 13:38:47] May 28, 2021 01:38:47 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 1518
[Warn  - 13:38:51] May 28, 2021 01:38:51 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 1548
[Warn  - 13:39:31] May 28, 2021 01:39:31 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 1793
[Error - 13:39:34] May 28, 2021 01:39:34 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError()
Message: Internal error: java.lang.OutOfMemoryError: Java heap space
java.util.concurrent.CompletionException: java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
	at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:718)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
	at java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
	at java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:1257)
	at java.base/java.util.concurrent.CompletableFuture$BiApply.tryFire(CompletableFuture.java:1279)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:295)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: java.lang.OutOfMemoryError: Java heap space
	at java.base/java.lang.Integer.toString(Integer.java:448)
	at java.base/java.lang.Integer.toString(Integer.java:1188)
	at com.google.gson.stream.JsonWriter.value(JsonWriter.java:528)
	at com.google.gson.internal.bind.TypeAdapters$7.write(TypeAdapters.java:232)
	at com.google.gson.internal.bind.TypeAdapters$7.write(TypeAdapters.java:217)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.Gson$FutureTypeAdapter.write(Gson.java:977)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:141)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:40)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.Gson$FutureTypeAdapter.write(Gson.java:977)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:141)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:40)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.Gson$FutureTypeAdapter.write(Gson.java:977)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:141)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:40)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)

[Error - 13:39:34] Request textDocument/documentSymbol failed.
  Message: Internal error.
  Code: -32603 
java.util.concurrent.CompletionException: java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
	at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:718)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
	at java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
	at java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:1257)
	at java.base/java.util.concurrent.CompletableFuture$BiApply.tryFire(CompletableFuture.java:1279)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:295)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: java.lang.OutOfMemoryError: Java heap space
	at java.base/java.lang.Integer.toString(Integer.java:448)
	at java.base/java.lang.Integer.toString(Integer.java:1188)
	at com.google.gson.stream.JsonWriter.value(JsonWriter.java:528)
	at com.google.gson.internal.bind.TypeAdapters$7.write(TypeAdapters.java:232)
	at com.google.gson.internal.bind.TypeAdapters$7.write(TypeAdapters.java:217)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.Gson$FutureTypeAdapter.write(Gson.java:977)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:141)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:40)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.Gson$FutureTypeAdapter.write(Gson.java:977)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:141)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:40)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)
	at com.google.gson.Gson$FutureTypeAdapter.write(Gson.java:977)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:141)
	at org.eclipse.lsp4j.jsonrpc.json.adapters.CollectionTypeAdapter.write(CollectionTypeAdapter.java:40)
	at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.write(TypeAdapterRuntimeTypeWrapper.java:69)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.write(ReflectiveTypeAdapterFactory.java:125)
	at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.write(ReflectiveTypeAdapterFactory.java:243)

From that point on, suggestions and problems stop working until I restart VS code, which fixes the issue until it re-occurs after a few minutes to about an hour. I haven't found a targeted way to trigger the behavior, it just seems to occur after some time of editing.

After the problem has occurred, the java.exe process seems to only take about 200 MB of RAM, the same it does after starting up.
Watching the memory usage during normal operation doesn't show any egregious memory problem (and any activity in this graph coincided with some typing activity):

Here's some details about my setup:

• I've set the xml.catalogs setting to contain a single entry, an XML catalog mapping a single name to my XML schema definition.
• I've tried setting xml.server.binary.args to -Xmx1g to no avail.
• All other settings of this extension are set to the default value.
• I'm running Windows and have installed this Java version:

  openjdk 16.0.1 2021-04-20
  OpenJDK Runtime Environment (build 16.0.1+9-24)
  OpenJDK 64-Bit Server VM (build 16.0.1+9-24, mixed mode, sharing)
  

• I'm running VS code 1.56.2 and version 0.16.1 of this extension (but I've had this problem for quite some time, so it's not related to any recent updates).

I'm not sure what else I can do to help debug this – if needed, I can share my XML schema and the document I'm editing, but I'd prefer not to post this publicly (sorry).

[angelozerr]

I'm not sure what else I can do to help debug this – if needed, I can share my XML schema and the document I'm editing, but I'd prefer not to post this publicly (sorry).

Could you send me your XMl and XML Schema files and XML catalog please.

[fefrei]

I sent you an email. Thanks for looking into this!

(Trying to reproduce this may take a lot of patience – I haven't been able to trigger this intentionally within 15 minutes, but I get it multiple times a day while working on the XML document. If there's any useful additional logging I could turn on, let me know!)

[angelozerr]

I suspect the problem comes from outline. I suggest several solutions:

• you customize the Java VM (if you are using Java and not binary) with xml.server.vmargs settings. See https://github.com/redhat-developer/vscode-xml/tree/f63fb7c5b507f978a7cc7eebe006e7dae1720047#supported-vs-code-settings
• you disable the outline. See https://github.com/redhat-developer/vscode-xml/blob/master/docs/Symbols.md#xmlsymbolsenabled
• you customize the max items with https://github.com/redhat-developer/vscode-xml/blob/master/docs/Symbols.md#xmlsymbolsmaxitemscomputed

[fefrei]

Thanks! I've disabled the outline (using the extension's setting) – I'll report back once the issue re-occurs, or in about a week if it doesn't.

you customize the Java VM (if you are using Java and not binary) with xml.server.vmargs settings

Is there any specific change you suggest? As mentioned, I already set -Xmx1g based on the description of the setting within VS code, whereas the online documentation suggests -Xmx1G -XX:+UseG1GC -XX:+UseStringDeduplication.

[fefrei]

Unfortunately, it looks like this wasn't the (only) cause. Despite the outline being disabled (which seems to have worked – the outline view now shows “no symbols found”), I got another memory exhaustion.

[angelozerr]

Thanks for your feedback! It's difficultto reproduce it since we should update the XML file while several minutes.

As mentioned, I already set -Xmx1g based on the description of the setting within VS code, whereas the online documentation suggests -Xmx1G -XX:+UseG1GC -XX:+UseStringDeduplication..

@rgrunber can you clarify that please?

I've tried setting xml.server.binary.args to -Xmx1g to no avail.

I'm running Windows and have installed this Java version:

I'm confused, did you start the XML Server with Jav aor with binary?

An interesting test is to try to update XML without XSD link. Do you think you could try it?

[fefrei]

It's difficultto reproduce it since we should update the XML file while several minutes.

I understand – if I ever find a way to reproduce this reliably, I'll let you know.

I'm confused, did you start the XML Server with Java or with binary?

I didn't configure anything for this, it just worked. I had installed Java anyways, and based on my reading of the settings, since I did not enable xml.server.preferBinary, it defaulted to the Java version. (VS Code spawns "C:\Program Files\OpenJDK\jdk-16.0.1\bin\java" -DwatchParentProcess=false -Xmx64M -cp c:\Users\fefrei\.vscode\extensions\redhat.vscode-xml-0.16.1\server\org.eclipse.lemminx-0.16.2-uber.jar org.eclipse.lemminx.XMLServerLauncher, so it's definitely using Java for now.)

I've now toggled the settings to prefer the binary, VS Code is now spawning C:\Users\fefrei\.vscode\extensions\redhat.vscode-xml-0.16.1\server\lemminx-win32.exe instead. I'll report back if I manage to crash this one, too.

An interesting test is to try to update XML without XSD link. Do you think you could try it?

I can try. Since this is somewhat annoying (I still don't know my XML Schema by heart), I'll try this after I crashed the binary version (or concluded that it works).

[angelozerr]

Thanks!

[rgrunber]

I see there's some suggestions being tried that might fix things, but I wanted to comment on the memory situation since this is very similar to what I've seen in another plugin ( redhat-developer/vscode-java#1262 ). The default JVM options were meant to optimize for an application that is always doing some processing. While language servers do some intense processing initially (eg. import the project/xml file, the above attached chart shows this nicely), they quiet down significantly afterwards, so it's a good opportunity to do garbage collection.

Basically, I would try something like : -XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m for xml.server.vmargs. You could even try with less than 1G as I don't think this extension would need that much, but the basic idea is that the additional options encourage the JVM to do more garbage collection when certain limits are hit.

Some may wonder why we don't make that the default. These options are specific to OpenJDK ( #278 ) and we ultimately decided to support more Java runtimes, while giving people the option to configure individually.

A good reference is :
https://developers.redhat.com/blog/2014/07/15/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-1
https://developers.redhat.com/blog/2014/07/22/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-2

[fefrei]

Thanks for the input! I'll add that to my list of things to try (which takes time due to the issue only occurring irregularly) – but it seems like this would make sense if the problem was that memory consumption slowly grew without every being garbage collected properly. I don't think that's the case her: I've never seen the java.exe process ever take more than 250 MB, far below the limit of 1G I had set, so it doesn't seem like the process is slowly creeping up to the limit, but, for some reason, decides to suddenly need at lot of RAM at once.

[fefrei]

After some days of editing, it looks like the binary version is completely stable for me.

For testing, I'll now return to the Java version, this time using the configuration recommended by @rgrunber (-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m). I'll report back when I know whether this is stable for me.

[angelozerr]

For testing, I'll now return to the Java version, this time using the configuration recommended by @rgrunber (-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m). I'll report back when I know whether this is stable for me.

Thanks so much! Your feedback is really important because if it works for you, we could define this setting as default. Thanks again for your patience!

[fefrei]

Hm, with these settings, something new happened! Once again, I've had the XML extension stop working (I got no suggestions anymore, and it failed to insert closing tags for me).

RAM usage looked OK:

However, this time, there was no OutOfMemoryError. Here's the full log I got:

[Info  - 10:08:00] Jun 10, 2021 10:08:00 org.eclipse.lemminx.XMLLanguageServer initialize()
Message: Initializing XML Language server
LemMinX Server info:
 - Version : 0.16.2
 - Java : C:\Program Files\OpenJDK\jdk-16.0.1
 - VM Version : 16.0.1
 - Git 544a8d4 - [maven-release-plugin] prepare release 0.16.2
[Info  - 10:08:01] Jun 10, 2021 10:08:01 org.eclipse.lemminx.extensions.contentmodel.uriresolver.XMLCatalogResolverExtension setCatalogs()
Message: Adding XML catalog './hybrid-documents/catalog.xml' with expand system id 'file:///c%3A/Users/felix/git/my-project/some-folder/catalog.xml' and root URI 'file:///c%3A/Users/felix/git/my-project/'.
[Warn  - 10:18:59] Jun 10, 2021 10:18:59 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 68
[Warn  - 10:19:59] Jun 10, 2021 10:19:59 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 201
[Info  - 10:31:24] Jun 10, 2021 10:31:24 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Info  - 10:31:24] Jun 10, 2021 10:31:24 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Info  - 10:31:24] Jun 10, 2021 10:31:24 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Info  - 10:31:24] Jun 10, 2021 10:31:24 org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint notify()
Message: Unsupported notification method: $/setTraceNotification
[Warn  - 12:44:13] Jun 10, 2021 12:44:13 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 815
[Warn  - 12:45:05] Jun 10, 2021 12:45:05 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 939
[Warn  - 14:11:07] Jun 10, 2021 02:11:07 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 1534
[Warn  - 14:11:29] Jun 10, 2021 02:11:29 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 1639
[Warn  - 14:13:03] Jun 10, 2021 02:13:03 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 1899
[Warn  - 14:13:10] Jun 10, 2021 02:13:10 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 1932
[Warn  - 14:13:12] Jun 10, 2021 02:13:12 org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation()
Message: Unmatched cancel notification for request id 1941

Based on timing, the last messages happend just before the problem occurred.

I'm not sure what to make of this – but for now, I'll switch to the binary version, again (to check whether that really made a difference or was just a lot of luck), and also re-enable the outline to introduce some additional stress.

...but I just realized that I configured the wrong setting xml.server.binary.args, not xml.server.vmargs. I've corrected that, and am continuing testing like this.

[fefrei]

An update: After setting the correct arguments, i.e. "xml.server.vmargs": "-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m", I experienced no problems anymore.
Based on how much I worked on my XML file in that time, this isn't a guarantee the issue is solved now, but I'd argue it's a rather strong hint.

I'll keep things configured like so and report back if I ever experience another memory problem, but I'm expecting to mostly work on other things for a while, so I'll be giving it fewer chances to crash in the nearer future.

Some may wonder why we don't make that the default. These options are specific to OpenJDK ( #278 ) and we ultimately decided to support more Java runtimes, while giving people the option to configure individually.

Maybe the extension could try to detect the JVM in use and use appropriate defaults (or just try passing these arguments by default, and re-try launching the JVM without them if it immediately quits with an error code)?