High CPU usage and memory consumption even if doing nothing

@wkia

originally reported by @wkia at microsoft/vscode-java-debug#1408

I'm working with OpenJDK 11/17/21/... source code on Windows 11, WSL, and Linux.

"Debugger for Java" is v0.55.0. This issue is related to #1330 (comment), but I tried to reproduce it from scratch.

The example from WSL, just open VSCode with my workspace and see - it consumes CPU and memory for a long time:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 6174 user      20  0   37.9g  14.2g   3.5m  S 832.9  91.0  11:57.35 /home/user/.vscode-server/extensions/redhat.java-1.24.0-linux-x64/jre/17.0.8.1-linux-x86_64/bin/java --add-modules=ALL-SYSTEM --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.nio.fs=ALL-UNNAMED -Declipse.application=org.eclipse.jdt.ls.core.id1 -Dosgi.bundles.defaultStartLevel=4 -Declipse.product=org.ecli+
And then, when memory is about to out, it looks like it drops the process and starts again - with a small amount of memory and high CPU usage, increasing memory consumption every sec.

Steps To Reproduce (on Win11/WSL)

Install VSCode on Win11, and install "Remote Development" extension pack

Open WSL terminal, and run the following commands:

git clone https://github.com/openjdk/jdk.git openjdk

cp MyApp.java openjdk (see below for MyApp.java source code)

cd openjdk

code . &

In VSCode, Install "Debugger for Java", "Language support for Java" to remote WSL.

In VSCode, open ~/openjdk/MyApp.java file in editor.

In WSL terminal, run top -c and see .vscode-server/extensions/redhat.java-1.24.0-linux-x64/jre/17.0.8.1-linux-x86_64/bin/java consuming CPU and memory. (in my case it consumes all CPU cores)

Wait patiently, and still click 'Increase memory' and 'Reload window' in VSCode if it asks, continue seeing RedHat java process in top -c list consuming CPU and RAM.

You could stop here, but you also can try to reach the maximum memory amount in WSL allocated for VSCode by clicking 'Increase memory'/'Reload window', and possibly you will see behaviour described in Cannot debug JDK17 itself with "Debugger for Java" v0.49.1 #1330 (comment)

(Optional) You could also try to close and open VSCode again, instead of 'Reload'ing window. It seems it helps to reproduce it faster.

MyApp.java
public class MyApp {
    public static void main(String[] args) {
        System.out.println("Hello world!");
        System.out.println("Sleeping...");
        Thread.sleep(20000);
        System.out.println("Finished");
    }
}

I tried to dump the "redhat.java" process consumed 14GB RAM, and open the dump with visualvm. See screentshots here microsoft/vscode-java-debug#1330 (comment)

Meet same problem

This is extremely annoying and happens daily for me.

Similar problems. on leaving my WSL dormant for the night I find it in the morning with 100% memory usage (24 GiB) and 40+ RedHat java agents running.

I disabled and reenabled the extension and it used initially high-cpu, but after few minutes it went down.

Same here, and we are using this extension at work and several of my colleagues are also blocked by this daily.

I'm still able to reproduce the issue with ".vscode-server/extensions/redhat.java-1.28.1-linux-x64/jre/17.0.10-linux-x86_64" on JDK11 sources:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5310 user 20 0 22.3g 14.6g 12.0m S 1390 93.4 28:44.33 /home/user/.vscode-server/extensions/redhat.java-1.28.1-linux-x64/jre/17.0.10-linux-x86_64/bin/jav+

However I noticed that now the issue occurs when I put my test into the root folder of downloaded JDK sources:

Clone JDK11: $ git clone https://github.com/openjdk/jdk11u-dev.git
$ cd jdk11u-dev
Copy existing test test/hotspot/jtreg/compiler/loopopts/TestLoopUnswitchingLostCastDependency.java into the root directory of JDK sources: $ cp test/hotspot/jtreg/compiler/loopopts/TestLoopUnswitchingLostCastDependency.java .
Open the current folder in in VSCode: $ code . &
Open ./TestLoopUnswitchingLostCastDependency.java in VSCode editor (use Ctrl+O, or whatever)
Wait, still clicking 'Increase memory' and 'Reload window' in VSCode if it asks, continue seeing RedHat java process in top -c list consuming CPU and RAM.

The issue still occurs with JDK17 sources.

I'm still facing the issue with redhat.java-1.30.0 on VSCode 1.89

Still there with VSCode 1.89.1 and redhat.java-1.31.0-linux-x64 on JDK17 sources.

Still here without Java extensions. Only writing latex with two vscode window open then the cpu will go to 60%-80%.

This extension appears to be abandoned. I've deleted it and use Android Studio for working on Java code.

@wkia

I can reproduce the issue when setting

"java.compile.nullAnalysis.mode": "automatic"

The imported projects contain javax.annotation.Nonnull, but don't contain javax.annotation.Nullable.
JDT null analysis requires both of the classes to be included in the projects. Otherwise, it will throw an AIOOB exception and rebuild the workspace.
Java LS enables null analysis even when any of these classes is present. I'm preparing a patch.

@wkia @maphdze @johnmccutchan @witlingw @archenroot @tonyganchev @zhiqiang-hhhh could you try to set

"java.compile.nullAnalysis.mode": "disabled"

Please check also <openjdk|jdk11u-dev|your_project_root>/.vscode/settings.json

Using version 1.32 now, I uninstalled the extensions, and install it again, the issue seems still there for me.

Also tried this setting in my workspace:
"java.compile.nullAnalysis.mode": "disabled"
it doesn't help.

Still consumes a lot of memory (growing up to OOM error), and CPU ~1400%.
Tested with jdk22 sources.

@wkia

Still consumes a lot of memory (growing up to OOM error), and CPU ~1400%.
Tested with jdk22 sources.

@wkia I can't reproduce the issue. "java.compile.nullAnalysis.mode": "disabled" isn't necessary anymore.
Could you, please, try the following:

Clean the workspace directory
attach your server log

@snjeza

I've cleaned workspace directory in both Windows and WSL. Removed ".vscode*" folders from $HOME and from the project directory.
The issue still occurs. Logs attached,
vscode.log

@snjeza Did you try to reproduce with the steps I provided at the very beginning?
See the description of the issue above, step 8: "In VSCode, open ~/openjdk/MyApp.java file in editor."
The issue starts occuring on the step 8, and it is continuing until I delete MyApp.java, and reload VSCode window.
You can even skip installing "Debugger for Java", install only "Language support for Java".

In my logs, I created a new file in VSCode (Ctrl+N), copy-n-pasted content of MyApp there, and saved as "openjdk/MyApp.java".

Did you try to reproduce with the steps I provided at the very beginning?

Yes, I did but still can't reproduce the issue.
Could you try to add

"java.jdt.ls.vmarg": "-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx4G -Xms100m -Xlog:disable",

Could you reproduce the issue outside of WSL?

Could you reproduce the issue outside of WSL?

Yes, I'm able to reproduce it on Windows 11:

All of the tries above ended up with OOM error:

Every time the issue occured I clicked "Increase..." again and again, so now my current workspace settings is:

.vscode/settings.json
{
    "java.jdt.ls.vmargs": "-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx8G -Xms100m -Xlog:disable"
}

For the following settings, the try ended up with OOM error on Windows 11:

{
    "java.jdt.ls.vmargs": "-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx4G -Xms100m -Xlog:disable",
    "java.trace.server": "verbose"
}

The logs:
vscode-win.log

As it is seen from logs, the reproducer took ~20 mins.
It consumed 60-80% of my i7-12700H.

No other extesions are installed, but "Language Support for Java(TM)" by Red Hat.

@wkia

@wkia Could you attach your settings.json?

@snjeza

@snjeza
User settings:
settings.json
Workspace setting:
settings.json

@wkia

@wkia Could you try the following:

set "java.import.maven.enabled": true,
exit VS Code
delete C:\Users\user\AppData\Roaming\Code\User\workspaceStorage - Clean the workspace directory
start VS Code

@wkia

Workspace setting:
settings.json

@wkia You can also try to add

"java.import.maven.enabled": false,
"java.project.sourcePaths": [
        "src"
    ]

and Clean the workspace directory

@snjeza

@snjeza Here are the results:

"java.import.maven.enabled": true - issue is NOT reproducible
"java.import.maven.enabled": false + "java.project.sourcePaths" - issue is NOT reproducible

Double checked without the changes above - issue is still reproducible.
Also, just in case checked, "java.import.maven.enabled": false only, without adding "java.project.sourcePaths" - issue is reproducible.

Cleaned workspace before each test case.

Tested on Windows 11, not WSL.

@snjeza

@snjeza I'm happy to use the setting above as a workaround, however I don't like an idea to tune settings for all new workspaces I create. Is it going to be fixed somehow in further releases?

@snjeza

@snjeza
The issue is still reproducible on Windows 11 with "test" folder rather than "src":

    "java.import.maven.enabled": false,
    "java.project.sourcePaths": [
            "test"
        ]

And it is still reproducible on WSL even with:

    "java.import.maven.enabled": true,

@wkia

@wkia Could you try the following:

$ wsl
$ rm -rf ~/.vscode-server/data/User/workspaceStorage # clean the workspace directory
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble
$ cd <openjdk>
$ sudo apt-get install autoconf make zip
$ bash configure
$ make eclipse-java-env
$ code .

See IDE support in the JDK

@snjeza

@snjeza It seems helping. Thanks!

Navigation Menu

Repository navigation

High CPU usage and memory consumption even if doing nothing #3387

Steps To Reproduce (on Win11/WSL)

MyApp.java

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

High CPU usage and memory consumption even if doing nothing #3387

Description

Steps To Reproduce (on Win11/WSL)

MyApp.java

Activity

wkia commented on Nov 10, 2023

RoanHeNaN commented on Dec 4, 2023

johnmccutchan commented on Dec 6, 2023

tonyganchev commented on Dec 14, 2023

archenroot commented on Dec 15, 2023

witlingw commented on Jan 25, 2024

wkia commented on Feb 26, 2024

wkia commented on Mar 5, 2024

wkia commented on May 9, 2024

wkia commented on Jun 3, 2024

maphdze commented on Jun 13, 2024

johnmccutchan commented on Jun 14, 2024

snjeza commented on Jun 16, 2024

7 remaining items

wkia commented on Jul 5, 2024

snjeza commented on Jul 5, 2024

wkia commented on Jul 5, 2024

snjeza commented on Jul 5, 2024

wkia commented on Jul 8, 2024

wkia commented on Jul 8, 2024

snjeza commented on Jul 12, 2024

wkia commented on Jul 13, 2024

snjeza commented on Jul 13, 2024

snjeza commented on Jul 13, 2024

wkia commented on Jul 15, 2024

wkia commented on Jul 16, 2024

wkia commented on Jul 22, 2024

snjeza commented on Jul 23, 2024

wkia commented on Aug 12, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions