Hacker News Reader

Comment by maxloh | Hacker News Reader

JavaScript is a garbage collected language, so no memory leak is possible.

Memory leaks may not be possible but resource leaks can be.

Many languages have tried to attach "disposers" to garbage collection events. The more common term in this case is "finalizer". As far as I know, no language has ever had a general-purpose, robust solution that works so well that it can just be used. Many have tried, and they all end up either deprecated, determined by the community to be a footgun, or backed down to some specialized use case (like picking up after file handles that are GC'd but the expected thing is still that normal user code closes them and this is explicitly pitched as an undesirable fallback, not the thing you should do).

No, there are some objects that need to be disposed explicitly.

For example, if you're using three.js, various WebGL resources need to be manually disposed: https://threejs.org/docs/index.html#manual/en/introduction/H...

Garbage collection doesn't prevent memory leaks. Nothing stops you from filling up a Map and never emptying it

Memory allocated for the map is supposed to be freed when the variable goes out of scope.

Nope. It's freed when there's nothing referencing it any longer, at the next garbage collect.

Here are common pitfalls: https://auth0.com/blog/four-types-of-leaks-in-your-javascrip...

It's not a leak if the memory is still referenced! A garbage-collected system can never leak memory.

You’re being pedantic. “Memory leak” is colloquially used when you have data in memory which accumulates and isn’t actively being used by the system.

The problem with that definition of "memory leak" is that it's not useful to programmers.

A more useful definition is memory that remains allocated unintentionally.

How is that more useful? According to your definition, languages have nothing to do with memory leaks, pro or contra.

I think programmers mainly care about memory leaks because of the potential negative consequences of using up too much memory -- programs crash or fail, or services frequently restart, or you have to provision additional costly server resources to keep things running well.

If your program continuously allocates memory that it doesn't free and doesn't serve a useful purpose, it doesn't really matter if it's, e.g., being referenced by some cache or just completely unreferenced -- it's still causing the same problem and has the same solution (that is, release the memory when you're done with it -- whether that's by calling "free" or clearing the reference, or whatever your memory management system has)

Reply on news.ycombinator.com