Deno language server OOMs when the project contains a massive JSON module

[domenic]

$ deno --version
deno 2.1.4 (stable, release, x86_64-pc-windows-msvc)
v8 13.0.245.12-rusty
typescript 5.6.2

Project consists of a single file:

import dict from "./jmdict_eng.json" with { type: "json" };

console.log(dict.tags["vn"]);

plus jmdict_eng.json being, for example, the unzipped version of the jmdict-eng-3.6.1+20241223123233.json.zip file from here.

A minimal deno.json to trigger the plugin might be necessary. I'm using the one from deno init.

The VS Code logs say

[Info  - 8:51:20 AM] Connection to server got closed. Server will restart.
Starting Deno language server...
  version: 2.1.4 (release, x86_64-pc-windows-msvc)
  executable: C:\Users\d\AppData\Local\Microsoft\WinGet\Packages\DenoLand.Deno_Microsoft.Winget.Source_8wekyb3d8bbwe\deno.EXE
Connected to "Visual Studio Code" 1.96.2
Enabling import suggestions for: https://deno.land
Refreshing configuration tree...
  Resolved Deno configuration file: "file:///C:/Users/d/OneDrive%20-%20domenic.me/Code/WIP/deno-oom-demo/deno.json"
Server ready.

<--- Last few GCs --->

[8500:00000261B30C8000]    15266 ms: Scavenge (interleaved) 3066.2 (3072.5) -> 3065.9 (3077.7) MB, pooled: 0 MB, 5.87 / 0.00 ms  (average mu = 0.171, current mu = 0.123) allocation failure; 
[8500:00000261B30C8000]    15934 ms: Mark-Compact (reduce) 3068.4 (3077.7) -> 3067.7 (3073.2) MB, pooled: 0 MB, 560.79 / 0.00 ms  (+ 0.2 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 569 ms) (average mu = 0.179

<--- JS stacktrace --->



#
# Fatal JavaScript out of memory: Ineffective mark-compacts near heap limit
#
==== C stack trace ===============================

	(No symbol) [0x00007FFF853D1ECC]
	CrashForExceptionInNonABICompliantCodeRange [0x00007FF76A6E8ECB+1325403]
	node_api_get_module_file_name [0x00007FF76A3D2A17+24281479]
	node_api_get_module_file_name [0x00007FF76A42EE4A+24659386]
	node_api_get_module_file_name [0x00007FF76A3AE5EC+24132956]
	node_api_get_module_file_name [0x00007FF76A4B9AE7+25227863]
	node_api_get_module_file_name [0x00007FF76A4CC984+25305332]
	node_api_get_module_file_name [0x00007FF76A4CC10B+25303163]
	CrashForExceptionInNonABICompliantCodeRange [0x00007FF76BA9C68D+21983517]
	node_api_get_module_file_name [0x00007FF76A4B7427+25217943]
	CrashForExceptionInNonABICompliantCodeRange [0x00007FF76A6B4F00+1112464]
	CrashForExceptionInNonABICompliantCodeRange [0x00007FF76AE57332+9117122]
	CrashForExceptionInNonABICompliantCodeRange [0x00007FF76B837D7A+19474442]
	(No symbol) [0x00007FF6EB9E06C6]
[Error - 8:51:36 AM] The Deno Language Server server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.

I understand that it might be unreasonable to support such large files. So, is there any way to exclude the Deno language server from trying to crawl them, and by doing so committing suicide?

[domenic]

Perhaps a dupe of #21409. deno.excludeFiles doesn't seem to work, though.

[bartlomieju]

You could try increasing available memory to the LSP by specifying:

{
    "deno.maxTsServerMemory": 8172
}

in .vscode/settings.json.

That said, we should investigate how the Deno LSP could be smarter about these huge files. Usually any file that is >=10Mb, should not be analyzed. CC @nayeemrmn @dsherret any ideas how we could that?