4 ms·

> If you are writing an application in Javascript, soon you will have to worry about memory leaks. I run a massive Node application and never had any issues wi

by Kiro 6y ago

> If you are writing an application in Javascript, soon you will have to worry about memory leaks. I run a massive Node application and never had any issues with memory leaks. I wouldn't even know how to forcefully create one even if I wanted to. I just code and never think twice about GC. How do people end up in situations where they need to start using stuff like WeakMaps?

seanwilson 6y ago
Maybe it's more common on the frontend? Complex UIs are a hotbed for leaks, where it can be a nightmare to figure out they're happening and the cause e.g. a previous screen or UI component not being destroyed properly so a table of data you generated to be displayed doesn't get collected. Just search the React and Angular GitHub issues for "memory leak".
winrid 6y ago
It depends on your application. I'm working on an application in Node right now that keeps hundreds of megabytes of configuration in memory since each model can take seconds to generate, and due to recent changes the # of models doubled. It's not a good design. I've been trying to get buy in on using an LRU cache... Also, I've worked in a few environments (Java and Node) where a spike of requests come into the system and prevent the GC from running - and then you run out of memory. I think that mostly went away with G1. We had a lot of stuff that ran on our customers sites and was prone to traffic spikes... I've learned that if you're not thinking about GC it usually bites you later. Better to think about performance, at least a little, up front.
hombre_fatal 6y ago
> I run a massive Node application and never had any issues with memory leaks. I wouldn't even know how to forcefully create one even if I wanted to. (1) I have no leaks and (2) I don't know how to create them -- These don't really square with each other. Leaks are easy. TFA mentions the classic one in UI apps: when you don't remove event listeners.
- Kiro 6y ago
  Yes, but this is not an UI app. I don't think I have leaks because memory sits at a fixed percentage even though I get hundreds of requests a second.
- joesb 6y ago
  > (1) I have no leaks and (2) I don't know how to create them -- These don't really square with each other. If he runs his service for a long time and the memory usage doesn't keep growing, no resource exhaustion problem occurs, then he can reasonably say he has no leaks. At least, he has no significant leaks. I don't have to know how to create nuclear bomb to know I don't have one.
gnulinux 6y ago
This doesn't make any sense. If you don't know how to create one, if you don't know how to test that you don't have leak, how can you know you don't have leaks? A simple python memory leak: a = get_a_huge_object() use_huge_object(a) # a function that takes long # that does not use a, but allocates more resources f() You can fix this by doing: # get_huge_object() returns a context manager # it deallocates at the end with get_huge_object() as a: use_huge_object(a) f() or even just: def g(): a = get_a_huge_object() use_huge_object(a) g() f() if you can rely on built-in deallocators. I hardly believe javascript code is divinely protected against something like this.
- siscia 6y ago
  That python one is not a memory leak, it is just uncareful use of resources.
  - gnulinux 6y ago
    I don't consider this to be correct since the main computation in that function will be done in `f()` where `a` is inaccessible and therefore cannot be deallocated. This is similar to mallocing `a` and then not free'ing. Obviously when the program dies python will deallocate everything, duh, that's not a useful definition of memory leak since even in a memory leaking C program, OS will clean up the memory after program dies. While the program is working though, it's going to keep leaking memory this way even in python.
    - Kiro 6y ago
      In JavaScript where there's often a single thread running a long-lived process I think the common case is when you keep allocating stuff through event handlers and not dereferencing them. A single wasteful build-up of memory is not really what I see discussed when people are discussing memory leaks in JS. As another commenter said, the classic case being adding UI event handlers and then removing the DOM object without dereferencing the handler. Doing this over and over will eventually make the app unresponsive but not immediately.
    - 6y ago

by Kiro 6y ago

seanwilson 6y ago

Maybe it's more common on the frontend? Complex UIs are a hotbed for leaks, where it can be a nightmare to figure out they're happening and the cause e.g. a previous screen or UI component not being destroyed properly so a table of data you generated to be displayed doesn't get collected. Just search the React and Angular GitHub issues for "memory leak".

winrid 6y ago

It depends on your application. I'm working on an application in Node right now that keeps hundreds of megabytes of configuration in memory since each model can take seconds to generate, and due to recent changes the # of models doubled. It's not a good design. I've been trying to get buy in on using an LRU cache... Also, I've worked in a few environments (Java and Node) where a spike of requests come into the system and prevent the GC from running - and then you run out of memory. I think that mostly went away with G1. We had a lot of stuff that ran on our customers sites and was prone to traffic spikes... I've learned that if you're not thinking about GC it usually bites you later. Better to think about performance, at least a little, up front.

hombre_fatal 6y ago

> I run a massive Node application and never had any issues with memory leaks. I wouldn't even know how to forcefully create one even if I wanted to. (1) I have no leaks and (2) I don't know how to create them -- These don't really square with each other. Leaks are easy. TFA mentions the classic one in UI apps: when you don't remove event listeners.

Kiro 6y ago
Yes, but this is not an UI app. I don't think I have leaks because memory sits at a fixed percentage even though I get hundreds of requests a second.
joesb 6y ago
> (1) I have no leaks and (2) I don't know how to create them -- These don't really square with each other. If he runs his service for a long time and the memory usage doesn't keep growing, no resource exhaustion problem occurs, then he can reasonably say he has no leaks. At least, he has no significant leaks. I don't have to know how to create nuclear bomb to know I don't have one.

gnulinux 6y ago

This doesn't make any sense. If you don't know how to create one, if you don't know how to test that you don't have leak, how can you know you don't have leaks? A simple python memory leak: a = get_a_huge_object() use_huge_object(a) # a function that takes long # that does not use a, but allocates more resources f() You can fix this by doing: # get_huge_object() returns a context manager # it deallocates at the end with get_huge_object() as a: use_huge_object(a) f() or even just: def g(): a = get_a_huge_object() use_huge_object(a) g() f() if you can rely on built-in deallocators. I hardly believe javascript code is divinely protected against something like this.

siscia 6y ago
That python one is not a memory leak, it is just uncareful use of resources.
- gnulinux 6y ago
  I don't consider this to be correct since the main computation in that function will be done in `f()` where `a` is inaccessible and therefore cannot be deallocated. This is similar to mallocing `a` and then not free'ing. Obviously when the program dies python will deallocate everything, duh, that's not a useful definition of memory leak since even in a memory leaking C program, OS will clean up the memory after program dies. While the program is working though, it's going to keep leaking memory this way even in python.
  - Kiro 6y ago
    In JavaScript where there's often a single thread running a long-lived process I think the common case is when you keep allocating stuff through event handlers and not dereferencing them. A single wasteful build-up of memory is not really what I see discussed when people are discussing memory leaks in JS. As another commenter said, the classic case being adding UI event handlers and then removing the DOM object without dereferencing the handler. Doing this over and over will eventually make the app unresponsive but not immediately.
  - 6y ago