Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
testforstephen opened this issue Nov 10, 2023 · 30 comments · Fixed by eclipse-jdtls/eclipse.jdt.ls#3196
Closed
Assignees
Milestone

Comments

@testforstephen
Copy link
Collaborator

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
Copy link

wkia commented Nov 10, 2023

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
Copy link

Meet same problem

@johnmccutchan
Copy link

This is extremely annoying and happens daily for me.

@tonyganchev
Copy link

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
Copy link

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

@witlingw
Copy link

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

@wkia
Copy link

wkia commented Feb 26, 2024

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
Copy link

wkia commented Mar 5, 2024

The issue still occurs with JDK17 sources.

@wkia
Copy link

wkia commented May 9, 2024

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

@wkia
Copy link

wkia commented Jun 3, 2024

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

@maphdze
Copy link

maphdze commented Jun 13, 2024

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

@johnmccutchan
Copy link

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

@snjeza
Copy link
Contributor

snjeza commented Jun 16, 2024

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
Copy link
Member

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.

@rgrunber rgrunber added the bug label Jun 18, 2024
@rgrunber rgrunber added this to the End June 2024 milestone Jun 18, 2024
@snjeza
Copy link
Contributor

snjeza commented Jun 18, 2024

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
Copy link

wkia commented Jul 5, 2024

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
Copy link
Contributor

snjeza commented Jul 5, 2024

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:

@wkia
Copy link

wkia commented Jul 5, 2024

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
Copy link
Contributor

snjeza commented Jul 5, 2024

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
Copy link

wkia commented Jul 8, 2024

Could you reproduce the issue outside of WSL?

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

image
image
image

All of the tries above ended up with OOM error:

image

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
Copy link

wkia commented Jul 8, 2024

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
Copy link
Contributor

snjeza commented Jul 12, 2024

@wkia Could you attach your settings.json?

@wkia
Copy link

wkia commented Jul 13, 2024

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

@snjeza
Copy link
Contributor

snjeza commented Jul 13, 2024

@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
Copy link
Contributor

snjeza commented Jul 13, 2024

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
Copy link

wkia commented Jul 15, 2024

@snjeza Here are the results:

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
Copy link

wkia commented Jul 16, 2024

@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
Copy link

wkia commented Jul 22, 2024

@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
Copy link
Contributor

snjeza commented Jul 23, 2024

@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
Copy link

wkia commented Aug 12, 2024

@snjeza It seems helping. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: ✅ Done
Development

Successfully merging a pull request may close this issue.

10 participants