-
Notifications
You must be signed in to change notification settings - Fork 297
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
Tracking Down A Memory Leak #1348
Comments
Hi! @sbrandt 😋 I've once investigated the same thing. Then, when you think about why it leaked, I can't shake the feeling that I've seen once somewhere that a recent memory leak was related to EPT or pointer compression1. However, I can't find anywhere a statement such as that the array of the That's all I knew about that problem! Footnotes |
Hi,
I have a long running service that creates (and destroys) many Deno runtimes over its lifespan. The service has slowly been leaking memory over time and I've been trying to investigate what the cause might be. What I've discovered is that an application that contains only the following code seems to leak memory:
I believe this to be case because I get the following when running DHAT:
The full DHAT viewer output can be seen in my test repository here [PDF]. The raw DHAT JSON output is also available there.
It looked like the WASM engine was responsible for some of the leaked memory, so I did a custom build of V8 without WASM as follows:
$ GN_ARGS="v8_enable_webassembly=false" V8_FROM_SOURCE=1 cargo build -vv
Running DHAT then gives the following output:
DHAT viewer output here [PDF].
I also tried both of the tests above with
jemallocator
, but that didn't make a huge difference. See the results of those tests in my test repo.Is my assumption correct that there should be no memory leaks (i.e.
t-end
should equal0
in the DHAT output above) with the simple code I provided?Am I doing something else wrong? Any tips on how I might be able to investigate further?
The text was updated successfully, but these errors were encountered: