High CPU usage and memory consumption even if doing nothing

[testforstephen]

originally reported by @wkia at https://github.com/microsoft/vscode-java-debug/issues/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)

1. Install VSCode on Win11, and install "Remote Development" extension pack
2. Open WSL terminal, and run the following commands:
3. git clone https://github.com/openjdk/jdk.git openjdk
4. cp MyApp.java openjdk (see below for MyApp.java source code)
5. cd openjdk
6. code . &
7. In VSCode, Install "Debugger for Java", "Language support for Java" to remote WSL.
8. In VSCode, open ~/openjdk/MyApp.java file in editor.
9. 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)
10. 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.
11. 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)
12. (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");
    }
}

[wkia]

I tried to dump the "redhat.java" process consumed 14GB RAM, and open the dump with visualvm. See screentshots here https://github.com/microsoft/vscode-java-debug/issues/1330#issuecomment-1803335715

[zhiqiang-hhhh]

Meet same problem

[johnmccutchan]

This is extremely annoying and happens daily for me.

[tonyganchev]

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.

[archenroot]

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

[witlingw]

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

[wkia]

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:

1. Clone JDK11: $ git clone https://github.com/openjdk/jdk11u-dev.git
2. $ cd jdk11u-dev
3. 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 .
4. Open the current folder in in VSCode: $ code . &
5. Open ./TestLoopUnswitchingLostCastDependency.java in VSCode editor (use Ctrl+O, or whatever)
6. 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.

[wkia]

The issue still occurs with JDK17 sources.

[wkia]

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

[wkia]

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

[maphdze]

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

[johnmccutchan]

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

[snjeza]

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

[rgrunber]

Definitely related to null analysis. I basically see the following error on repeat (using just the instructions at https://github.com/redhat-developer/vscode-java/issues/3387#issuecomment-1963708894 ). It's not extremely consistent, as there's a few instances where it it didn't enter a loop but there's definitely a problem.

!ENTRY org.eclipse.core.resources 4 75 2024-06-18 15:23:18.806
!MESSAGE Errors occurred during the build.
!SUBENTRY 1 org.eclipse.jdt.core 4 75 2024-06-18 15:23:18.806
!MESSAGE Errors running builder 'Java Builder' on project 'Settings'.
!STACK 0
java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getType(LookupEnvironment.java:1829)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.initializeUsesNullTypeAnnotation(LookupEnvironment.java:1684)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.usesNullTypeAnnotations(LookupEnvironment.java:1659)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.scanFieldForNullAnnotation(BinaryTypeBinding.java:2028)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:645)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:1080)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:1061)
	at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:307)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:368)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:624)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:696)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleImport(CompilationUnitScope.java:953)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:3551)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:3274)
	at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:60)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:525)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:637)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:633)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:605)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1644)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:1176)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1451)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:409)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment$CompleteTypeBindingsSteps.perform(LookupEnvironment.java:185)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:558)
	at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:880)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:393)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:447)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:425)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:410)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:211)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:341)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:79)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:286)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:198)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1077)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Setting java.compile.nullAnalysis.mode to disabled is one way to work around the issue.

[snjeza]

It's not extremely consistent...

You can consistently reproduce it in the following way:

• set "java.compile.nullAnalysis.mode": "automatic"
• import the openjdk project
• Open the command palette (F1)
• select Java: Force Java Compilation
• select Full

[wkia]

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.

[snjeza]

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

[wkia]

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".

[snjeza]

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?

[wkia]

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"
}

[wkia]

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.

[snjeza]

@wkia Could you attach your settings.json?

[wkia]

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

[snjeza]

@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

[snjeza]

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

[wkia]

@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.

[wkia]

@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?

[wkia]

@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,

[snjeza]

@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

[wkia]

@snjeza It seems helping. Thanks!