Maven spring-boot:run slows down Java and TS/JS language servers

[khe817]

When I start $ mvn spring-boot:run command in a bash command line window. The Java and TS/JS language servers switch to being very slow with response time for live hover hint around 7000ms (normally it's within 20ms - 30ms):

[Trace - 11:51:59 AM] Sending request 'java/findLinks - (24)'.
Params: {
    "type": "superImplementation",
    "position": {
        "textDocument": {
            "uri": "file:///home/user/.../PublicationIndexController.java"
        },
        "position": {
            "line": 31,
            "character": 13
        }
    }
}

[Trace - 11:52:06 AM] Received response 'java/findLinks - (24)' in 6999ms.
Result: []

• VSCode Version: 1.52.0
• OS Version: WSL v.2 (Window Subsystem in Linux version 2) version "4.19.128-microsoft-standard" inside "Windows_NT x64 10.0.18363"

Steps to Reproduce:

1. Open a project in VScode with redhat.java (uses Java language server) and baeumer.vscode-eslint (uses TS/JS language server) extensions enabled. Test live hover hint to see that it works normally.
2. Open an independent bash command line window (does not matter if it's a terminal inside VSCode or outside VSCode) in WSL. Run command $ mvn spring-boot:run. Wait for Spring Boot to finish starting up.
3. Try live hover hint in VSCode again. This time, it's very slow.

Related issue I opened in redhat.java repository: redhat-developer/vscode-java#1743

[mjbvz]

Can you also please follow these instructions to collect performance information when this is happening. A good starting point would be the output of code --status

[khe817]

Thank you for replying!

Here is the output of code --status when I had VScode open with TS/JS language server running and $ mvn spring-boot:run command running in a terminal window:

$ code --status

Version:          Code 1.52.0 (940b5f4bb5fa47866a54529ed759d95d09ee80be, 2020-12-10T22:45:11.850Z)
OS Version:       Windows_NT x64 10.0.18363
CPUs:             Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz (8 x 1896)
Memory (System):  31.82GB (18.26GB free)
VM:               0%
Screen Reader:    no
Process Argv:     --folder-uri=vscode-remote://wsl+Ubuntu-20.04/home/user/Documents/my_work/vscode-ping-endpoint --remote=wsl+Ubuntu-20.04 --crash-reporter-id e7886464-58b0-4f5f-9c86-0c928d60922c
GPU Status:       2d_canvas:                  enabled
                  flash_3d:                   enabled
                  flash_stage3d:              enabled
                  flash_stage3d_baseline:     enabled
                  gpu_compositing:            enabled
                  multiple_raster_threads:    enabled_on
                  oop_rasterization:          disabled_off
                  opengl:                     enabled_on
                  protected_video_decode:     enabled
                  rasterization:              enabled
                  skia_renderer:              disabled_off_ok
                  video_decode:               enabled
                  vulkan:                     disabled_off
                  webgl:                      enabled
                  webgl2:                     enabled

CPU %   Mem MB     PID  Process
    1      141    6060  code main
    1      254    3348     window (ping_helper.js - vscode-ping-endpoint [WSL: Ubuntu-20.04] - Visual Studio Code [Administrator])
    0       57   15408       extensionHost
    0       26   13500         electron_node wslDaemon.js 
    0       12   10272     crashpad-handler
    0       61   12292     window (Process Explorer)
    0       28   16028     utility
    0      255   16060     gpu-process
    0       67   16136     shared-process
    0      166   17104     window (undefined)



Remote:           WSL: Ubuntu-20.04
OS Version:       Linux x64 4.19.128-microsoft-standard
CPUs:             Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz (8 x 1896)
Memory (System):  24.92GB (21.97GB free)
VM:               0%

I ran Javascript Profiling in Developer Tools from when VSCode running normally with TS/JS language server running to after starting up $ mvn spring-boot:run in the terminal that slowed TS/JS language server's live hover hints down:

CPU-20201215T132141.cpuprofile.txt

I opened Developer: Show Running Extensions, selected TS and JS Language Features extension and ran extension profiling while $ mvn spring-boot:run is running in the terminal:

CPU-20201215T183530.689Z.cpuprofile.txt

Note that all of these are running under Remote - WSL extension.

Any helps are very much appreciated!

[mjbvz]

hm, that doesn't show anything odd from VS Code itself. What does the system resource usage look like? Is Maven spring-boot:run using a lot of resources? Does it set up a lot of file watchers?

[khe817]

$ mvn spring-boot:run normally is not resource intensive. But after the upgrade, every time I start the 2 up (VSCode and Maven Spring Boot run at the same time), the CPU is always in the 40 percentage range:

The Vmmem process is the virtual machine by WSL2.

$ mvn spring-boot:run starts up a JVM server that has 1 file watcher thread:

[mjbvz]

This sounds like an issue with wsl to me but @aeschli or @deepak1556 may know more.

I'm going to unassign myself since this does not seem JS/TS specific

[alexdima]

This might be caused by our new automatic port forwarding feature which scans the remote OS for available ports in order to forward them locally (#112843)

[alexr00]

@khe817 would you be willing to try the following steps? This would help us confirm that we've found the issue, and you'll also get to use a more up-to-date version.

1. On your remote machine, add the following line to your .bashrc file: export VSCODE_DISABLE_PROC_READING=true
2. Install VS Code Insiders
3. Try to repro your original issue with VS Code Insiders.

Setting that environment variable will cause VS Code (insiders only right now, I'll make a proper fix that doesn't involve an environment variable for the next stable release), to not do the proc filesystem reading that we do to automatically forward ports for you. This does mean that automatic port forwarding will not work while you have that environment variable set.