cody

cody copied to clipboard

• Tree-sitter WASM bindings usage causes V8 external memory to grow linearly with the number of documents parsed with no clear way to free it.
• Unit test for reproduction https://github.com/sourcegraph/cody/pull/3788
• Related GitHub threads: #1, #2, #3
• I'm able to clean up the V8 external memory that grows in tests, but for that, I hacked a couple of changes into the pre-build tree-sitter WASM bindings. With them, I re-create a new parser instance after parsing 10k documents which allows GC to clean up the previously created WebAssembly.Memory instance
• Slack thread.

This issue is marked as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed automatically in 5 days.

@valerybugakov I've run into a similar issue with web-tree-sitter, is there something you recommend for freeing the memory from a vscode extension using the wasm vs altering the wasm itself?

One of my extensions' users is saying that even after updating the extension/restarting vscode, there is still some memory leak causing significant performance issues in the extension, so I'm thinking vscode is holding onto whatever memory was allocated for the wasm because it failed and got into a problematic state. I would assume restarting the extension would clear this memory but that doesn't seem to be the case. I want to add something to my extensions activation to clear up this used memory for this user that was affected v.s. having him clear out his vscode cache for example.

This issue is marked as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed automatically in 5 days.

Hey @saoudrizwan! Check out this PR for the solution we came up with: https://github.com/sourcegraph/cody/issues/5460