Cannot debug JDK17 itself with "Debugger for Java" v0.49.1

[wkia]

trafficstars

I'm building and debugging OpenJDK 17 on Windows 11. I'd like to debug it with VSCode. I submitted the issue #1285 before for other version of extensions, but now Java Debugger extension seems totally broken.

1. I have disabled "build before launch" for both User and Workspace, but every time I run the debug configuration (see below), I see the message about "Debug 'Launch Java Program': compiling..." and then "Build failed, do you want to continue?" with a lot of compilation errors.
2. It can debug source of my tests, but it cannot step in JDK classes. It seems like it cannot find neither source files, not debug info for fresh built fast-debug JDK.
3. If I open one of JDK java-files in VSCode and try run the debugger (the same configuration), it shows "Debug 'Launch Java Program': compiling...", and may hang until OutOfMemory error occurs.
4. I have set "java.configuration.runtimes" option to manually downloaded JDK, but, in TaskMonitor, I still see Java.exe process running from "C:\Users\username\.vscode\extensions\redhat.java-1.17.0-win32-x64\jre\17.0.6-win32-x86_64\bin". It looks like scanning my JDK source files, but cannot do this properly. It consumes a lot of memory (1GB+), and reports about OutOfMemory error in VSCode time to time.

Is it really broken now? Is my configuration wrong maybe?

Environment

• Operating System: Windows 11
• JDK version: 17
• Visual Studio Code version: 1.77.3
• Extension Pack for Java: v0.25.10
• Debugger for Java: v0.49.1
• Language Support for Java(TM) by Red Hat: v1.17.0

My setting.json:

    "java.configuration.runtimes": [
        {
            "default": true,
            "name": "JavaSE-17",
            "path": "c:\\Users\\username\\work\\jdk"
        }
    ]
    "java.debug.settings.onBuildFailureProceed": false,
    "java.debug.settings.forceBuildBeforeLaunch": false

My launch.json:

        {
            "type": "java",
            "name": "Launch Java Program",
            "request": "launch",
            "cwd": "${workspaceFolder}\\jdk\\myjdk\\MyJdkTest\\MyJdkTest",
            "mainClass": "jdk.test.lib.myjdk.MyJdkTest",
            "vmArgs": "-ea <other vm args>",
            "args": "<java test args>",
            "classPaths": [
                "${workspaceFolder}\\classes\\jdk\\myjdk\\MyJdkTest\\MyJdkTest.d",
                "${workspaceFolder}\\classes\\test\\lib"
            ],
            "javaExec": "c:/Users/username/work/myjdk/build/windows-x86_64-server-fastdebug/jdk/bin/java.exe",
        },

[testforstephen]

In launch mode, the debugger will always force you to compile the code. It's either autobuild or a force compilation before launch. If you wanto to avoid the compilation from Java extension, then you can use attach mode instead.

To use attach mode, you need to configure a task in tasks.json to launch the JDK program by yourself, and then configure an attach config in launch.json to launch them together. You can find a sample config on the link https://github.com/microsoft/vscode-java-debug/issues/120#issuecomment-417269773.

{
            "type": "java",
            "name": "Attach",
            "request": "attach",
            "hostName": "localhost",
            "port": "<debug port of the debuggee>",
            "preLaunchTask": "<your launch task in tasks.json>"
}

[wkia]

@testforstephen Thanks for your answer! It may help me with debugging in future.

However there are still items 2), 3), and 4) in my report. They don't seem like questions, they look like the extension's problems for me, especially 3) and 4). I don't think they are related to the approach I use to start a debugger. Is there a workaround for them?

[testforstephen]

For 2), It's hard to say what's wrong. It's better to provide a minimum sample project to reproduce the issue.

For 3), you can try to add more -Xmx memory to Java extension by changing the setting "java.jdt.ls.vmargs": "-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m -Xlog:disable"

4. TaskMonitor, I still see Java.exe process running from "C:\Users\username.vscode\extensions\redhat.java-1.17.0-win32-x64\jre\17.0.6-win32-x86_64\bin"

This is the JVM process of RedHat Java language support extension, used to serve language features such as code completion, compilation, etc.

[wkia]

For 4), I believed that ""java.configuration.runtimes"" setting is to specify which JDK should be used by VSCode. It seems ignored, because VSCode still download and use RH JRE, so what is "java.configuration.runtimes" setting for?

[wkia]

For 3), currently I use -Xmx2G value (suggested by VSCode on OOM error occured). Not sure if it will fail with OOM or not, need to test it. But at the moment I can see Java.exe from RedHat JRE, consuming 2GB RAM, as well as 55% CPU usage, for a long time. Is it OK?

UPDATE: I'm doing nothing, waiting for the VSCode stops consuming resources. I've just got OutOfMemory error with the setting above. But java.exe still running with 2GB RAM and 55% CPU usage. Now VSCode suggested to increase memory to 4GB.

[testforstephen]

For 3), currently I use -Xmx2G value (suggested by VSCode on OOM error occured). Not sure if it will fail with OOM or not, need to test it. But at the moment I can see Java.exe from RedHat JRE, consuming 2GB RAM, as well as 55% CPU usage, for a long time. Is it OK?

Could you share the thread dump to help us understand what tasks are consuming high CPU usage?

Here are the steps for thread dump:

1. Close the irrelevent VS Code windows except the current one.
2. In the terminal, run the jps command and look for the pid of the process named “org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar”.

>jps
23492 Jps
3940 Main
20524 GradleDaemon
20924 org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar       <==== This is the pid of Java extension process

3. In the terminal, run jstack <pid> to dump threads of Java extension

>jstack 20924

For 4), I believed that ""java.configuration.runtimes"" setting is to specify which JDK should be used by VSCode. It seems ignored, because VSCode still download and use RH JRE, so what is "java.configuration.runtimes" setting for?

Java extension is written by Java code, it uses its embedded JRE to launch the extension itself, that's why you see a JVM process from "C:\Users\username.vscode\extensions\redhat.java-1.17.0-win32-x64\jre\17.0.6-win32-x86_64\bin". This Java process usually scans your workspace folder to infer the possible source directories and compile your workspace.

"java.configuration.runtimes" is used to specify the JDK libraries used by your own code and the JRE to run your code.

[wkia]

After the latest extension update, it seems it started using redhat-java-1.18. It still consumes CPU, maybe not so long as before. And it still want to increase memory. java_threads.txt

[wkia]

Now it is v0.55.0. Still having issues. 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.

Not sure I understand what it's trying to achieve.

[wkia]

Maybe this helps to localize the issue