Repository navigation
Language Support for Java [1.56.0] - Out of memory error #4506
Description
Activity
- Reacted by Bartek-Trz
This may be a symptom of a VSCode issue. I'm running VSCode on a remote RockyLinux system from a local Windows10 Pro host. My local Windows 10 Pro host is a guestVM running on robust local iron also running RockyLinux.
I grant that this is a complex tool chain, but the benefit is that everything that matters stays on an AWS EC2 instance. I don't have to even think about moving or sharing files between Windows and Linux, for example. Similarly, I just run git from an SSH shell running on the server. Still, the several links of this chain might well contribute to the issues I see with copy/paste behavior, double-click handling, and so on.
I am seeing symptoms of Java memory leaks more and more frequently as VSCode adds more and more AI slop.
These usually happen while I'm refactoring Java code. I generally have multiple tabs open, and VSCode has trouble keeping up with simple double-click/copy/paste behavior. One frequent trouble spot is copying a fragment of text from one place to another -- either code or comment text. When I attempt to paste using CTRL-V, I get a spinning cursor for lengthy periods, sometimes forever. When this occurs, the only reliable workaround is to close and then reopen the VSCode window. After the "Language Support for Java" extension does its thing (I wait to see "Java ready" in the status bar along the bottom of the window), copy/paste works again for awhile.
Similarly, if I'm in a VSCode tab in the "Run & Debug" view while debugging (I often practice test-driven development, so I frequently set a breakpoint in the Java code and let VSCode open a tab if needed), then VSCode frequently ignores my attempts to copy text from tab altogether. The workaround for that issue is to change from "Run & Debug" to "Explorer" -- and sometimes kill the running test process.
I would prefer the developers to focus on improving copy/paste behavior and memory leaks rather than adding more and more "features".
I already rely on a recent and minimal version of notepad++ to do most of my code refactoring. VSCode is already so invasive that it's tedious to do most straightforward code rafactoring.
VSCode is a great tool and I use it pretty much all day every day. The inconvenience of dealing with bugs like this outweighs the any possible benefits from yet more editor "features".
I am seeing symptoms of Java memory leaks more and more frequently as VSCode adds more and more AI slop.
It's true for sure, but does not apply to this issue - I downgraded only Language Support, stayed with latest VSCode, and OOM errors stopped appearing.
(....) When I attempt to paste using CTRL-V, I get a spinning cursor for lengthy periods, sometimes forever.
My workaround is to use Ctrl + Shift + V. It works like simple "text" paste without code context, so it won't automatically add necessary imports but has no delay and is sufficient for simple copying.
Similarly, if I'm in a VSCode tab in the "Run & Debug" view while debugging (I often practice test-driven development, so I frequently set a breakpoint in the Java code and let VSCode open a tab if needed), then VSCode frequently ignores my attempts to copy text from tab altogether. The workaround for that issue is to change from "Run & Debug" to "Explorer" -- and sometimes kill the running test process.
I'd add that sometimes VSCode "loses contact" with the application executed in Run & Debug and you can't find it to stop it (e.g. when you close the terminal window). In such case the only way (that I'm aware of) is to find the process in Task Manager and kill it. Otherwise the TCP port will be occupied and you can't execute your app again.
Reacted by SomervilleTomThanks for the report and the crash log.
The attached log confirms that the Java Language Server exhausted memory: after running for about 9 hours, the old generation reached approximately 12.3 GB and remained 99% occupied after GC. The server was configured with
-Xmx32Gon a host with about 15 GB of RAM, so the JVM eventually failed to commit additional native memory.Version 1.56.0 bundles JDT LS 1.61.0, while 1.55.0 bundles JDT LS 1.59.0. We need heap information to identify which objects are being retained.
Could you please:
- Set
java.jdt.ls.vmargsto-Xmx4Gor-Xmx8G, restart VS Code, and reproduce the problem. This should produce a Java heap dump instead of a native-memory crash. - Try setting
"java.jdt.ls.mavenProjectCacheSize": 1and let us know whether memory still grows. - Provide the number of Maven modules/POM files, the Java Language Server output, and the workspace
.metadata/.log. - If possible, provide a heap histogram or dominator-tree screenshot. Please do not upload the full
.hprofpublicly if the project contains sensitive information.
The
-Xmx32Gconfiguration increases the likelihood of this crash, but it does not explain why downgrading to 1.55.0 resolves the problem, so we will continue treating this as a possible regression.- Set
I had similar issues and what I've been seeing is that there was a fallback introduced in 1.56.0 where a second JDT server is started and running against the same redhat.java/jdt_ws directory, one server is started with a --pipe and the other in --stdio. This causes a cache that is corrupt to be created and can take up a large amount of memory. This can be seen by running
pgrep -af 'org.eclipse.equinox.launcher.*jdt_ws'
and seeing two processes. It can be possible to also work around this by ensuring both processes are gone after closing VS Code and starting it back up and then cleaning the server workspace cache. Each fresh start of VS Code will resurface this issue. It's possible that this is an entirely different bug than was described in the original, but for me, it did start to surface on updating to 1.56.0.@wenytang-ms : I appreciate your attention.
I'll attempt to gather this data starting today.
-
Set java.jdt.ls.vmargs to -Xmx4G or -Xmx8G, restart VS Code, and reproduce the problem. This should produce a Java heap dump instead of a native-memory crash
-
Try setting "java.jdt.ls.mavenProjectCacheSize": 1 and let us know whether memory still grows.
I'll edit my ".vscode/settings.json" to reflect these changes
-
Provide the number of Maven modules/POM files, the Java Language Server output, and the workspace .metadata/.log.
-
If possible, provide a heap histogram or dominator-tree screenshot. Please do not upload the full .hprof publicly if the project contains sensitive information.
I don't know how to gather this information. Just to clarify my toolchain -- I run VSCODE on a local Windows 10 Pro, and I use the "Remote SSH" extension so that all of the above is done on a remote AWS` EC2 instance running RockyLinux 8.
I'm therefore not clear about where to gather the above information.
If it's helpful, here is the "pom.xml" file for your convenience:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.zeetix.gate.daemon</groupId> <artifactId>server</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <name>ZeetixGateDaemon</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties> <dependencies> <!-- <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> --> <!-- <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13</version> <scope>test</scope> </dependency> --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.2</version> <scope>test</scope> </dependency> <dependency> <groupId>org.json</groupId> <artifactId>json</artifactId> <version>20180130</version> <scope>compile</scope> </dependency> <dependency> <groupId>uk.ac.gate</groupId> <artifactId>gate-core</artifactId> <version>9.0.1</version> <scope>compile</scope> <exclusions> <!-- exclude the log4j1.x -> slf4j bridge as log4j2 can capture log4j1 logs directly --> <exclusion> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>com.sun.net.httpserver</groupId> <artifactId>http</artifactId> <version>20070405</version> </dependency> <dependency> <groupId>io.github.hakky54</groupId> <artifactId>sslcontext-kickstart-for-pem</artifactId> <version>9.0.0</version> </dependency> <!-- <dependency> <groupId>io.github.hakky54</groupId> <artifactId>sslcontext-kickstart-for-pem</artifactId> <version>7.4.11</version> </dependency> --> <!-- To direct log4j1 API calls to log4j2 --> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-1.2-api</artifactId> <version>2.20.0</version> </dependency> <!-- To direct slf4j API calls to log4j2 --> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> <version>2.20.0</version> </dependency> <dependency> <groupId>com.google.code.gson</groupId> <artifactId>gson</artifactId> <version>2.13.1</version> </dependency> <!-- <dependency> <groupId>uk.ac.gate.plugins</groupId> <artifactId>annie</artifactId> <version>9.1</version> </dependency> --> </dependencies> </project>I also had another out-of-memory error yesterday, using the prior version (v1.55.0) of the extension.
I have attached yesterday's log:
-
@Bartek-Trz @SomervilleTom Could you try pre-release 1.57.2026092508 after a clean restart? This version includes the revert in #4503 and still bundles Java 21.
Version 1.56.0 introduced a startup fallback that could leave the original language server running while starting a second one. This may be relevant to the OOM, but we have not confirmed it as the cause.
Downgrading alone does not reset the language-server workspace. To rule out leftover processes or cached workspace state, please:
- Save the existing logs first using Java: Open All Log Files, as the cleanup removes them.
- On the Java extension page, use Install Another Version… to select 1.57.2026092508 specifically—not the latest pre-release. Temporarily disable automatic updates for this extension during testing. For Remote SSH, install it on the remote host.
- Close the affected VS Code window and ensure any remaining JDT LS processes for that workspace have exited. For Remote SSH, check processes on the remote host rather than the local machine.
- Reopen the workspace, run Java: Clean Java Language Server Workspace, and select Reload and delete. This rebuilds the language-server state without deleting your project source files.
After project import finishes, please retest the same workspace. If the OOM persists, share the new client/server logs and check whether multiple JDT LS processes point to the same
jdt_wsdirectory. Please redact sensitive information before sharing.@SomervilleTom Please also use the previously suggested
-Xmx4Gor-Xmx8Grather than-Xmx32Gon your approximately 15 GB host. This is a separate memory-pressure risk, regardless of the extension version.@wenytang-ms I changed
settings.jsonto use 8G:{ "java.configuration.updateBuildConfiguration": "disabled", "java.debug.settings.onBuildFailureProceed": false, "java.debug.settings.showHex": true, "java.debug.settings.showQualifiedNames": false, "java.jdt.ls.mavenProjectCacheSize": 1, "java.jdt.ls.vmargs": "-XX:+UseParallelGC-XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx8G -Xms100m -Xlog:disable" }I'll try the suggested changes when I get a chance, I'm up to my ears at the moment and VSCode is working well enough that I don't to risk possibly invasive changes.
Describe the bug
After updating to 1.56.0 "Out of memory" errors started to appear with suggestion to increase limit.
After downgrade to 1.55.0 they don't show up any more.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No "Out of memory errors" :).
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
Additional Information