High CPU usage and memory consumption even if doing nothing

[testforstephen]

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)

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 microsoft/vscode-java-debug#1330 (comment)

[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 #3387 (comment) ). 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