Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How JavaScript works: memory management and common memory leaks

blog.sessionstack.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: How JavaScript works: memory management and common memory leaks

#51

Post by dingo_bat »

paulddraper wrote: post #16
vvanders wrote: post #4

Wait, is #3 for real? If that's the case it seems like a huge oversight.

Yeah. I thought so too (and still think so). SO post: https://stackoverflow.com/questions/19798803/how-javascript-... Chrome bug report: http://crbug.com/315190 Meteor blog (linked in article): https://blog.meteor.com/an-interesting-kind-of-javascript-me... Live example (will crash due to memory leak): https://s3.amazonaws.com/chromebugs/memory.html --- The reason this exists in all JS engines is for performance; it'…

> Live example (will crash due to memory leak): https://s3.amazonaws.com/chromebugs/memory.html

Happy to report that no crash in Nightly.

Edit: No crash in Edge either.

Re: How JavaScript works: memory management and common memory leaks

#52

Post by chillacy »

cel1ne wrote: post #49

The main problem with JS being sluggish (in electron apps for example) is memory and especially the GC. I can optimize CPU usage all I want, but only after I optimized for minimum allocations, the tiny, but noticeable lags now and then would disappear. The average javascript-GC must be really simple/naive compared to seasoned workhorses like the JVM's various GCs. There I can happily create millions of short-lived ob…

Well, you can run JS on the JVM through Oracle's Rhino (now Nashorn), but apparently perf is still largely worse than Sunspider or V8. The language doesn't lend itself to optimization as much as java does for JVM bytecode: https://blogs.oracle.com/nashorn/nashorn-architecture-and-pe...

Re: How JavaScript works: memory management and common memory leaks

#53

Post by paulddraper »

dingo_bat wrote: post #51
paulddraper wrote: post #16

Earlier quoted context omitted.

Yeah. I thought so too (and still think so). SO post: https://stackoverflow.com/questions/19798803/how-javascript-... Chrome bug report: http://crbug.com/315190 Meteor blog (linked in article): https://blog.meteor.com/an-interesting-kind-of-javascript-me... Live example (will crash due to memory leak): https://s3.amazonaws.com/chromebugs/memory.html --- The reason this exists in all JS engines is for performance; it'…

> Live example (will crash due to memory leak): https://s3.amazonaws.com/chromebugs/memory.html Happy to report that no crash in Nightly. Edit: No crash in Edge either.

It'll crash Chrome because it puts stricter limits on JS memory. (Or something.)

Firefox and Edge won't crash, but you'll be using 3GB+.

Re: How JavaScript works: memory management and common memory leaks

#54

Post by ufo »

def0wt wrote: post #50

> To prevent these mistakes from happening, add 'use strict'; at the beginning of your JavaScript files. This enables a stricter mode of parsing JavaScript that prevents accidental global variables. I don't think using strict will prevent accidental global variables, such as this.var in global scoped function calls. Strictness main goal is to prevent inadvertently misspelled variables from going unnoticed.

Iirc, if you use strict the this gets set to null by default instead of the global object

Re: How JavaScript works: memory management and common memory leaks

#55

Post by dingo_bat »

paulddraper wrote: post #53
dingo_bat wrote: post #51

Earlier quoted context omitted.

> Live example (will crash due to memory leak): https://s3.amazonaws.com/chromebugs/memory.html Happy to report that no crash in Nightly. Edit: No crash in Edge either.

It'll crash Chrome because it puts stricter limits on JS memory. (Or something.) Firefox and Edge won't crash, but you'll be using 3GB+.

Yup Firefox was at 3.6GB and edge at 2.8GB.

Re: How JavaScript works: memory management and common memory leaks

#56

Post by unkown-unknowns »

cel1ne wrote: post #49

The main problem with JS being sluggish (in electron apps for example) is memory and especially the GC. I can optimize CPU usage all I want, but only after I optimized for minimum allocations, the tiny, but noticeable lags now and then would disappear. The average javascript-GC must be really simple/naive compared to seasoned workhorses like the JVM's various GCs. There I can happily create millions of short-lived ob…

Probably part of the problem is also the fact that JavaScript is a very dynamic language.

I think even the JVM team would struggle to improve on the state of the art in js vm tech. Their experience in making JVM might not be all that useful in the context of js.

Re: How JavaScript works: memory management and common memory leaks

#57

Post by wahern »

IgorPartola wrote: post #5
vvanders wrote: post #4

Wait, is #3 for real? If that's the case it seems like a huge oversight.

Yeah, of the four things listed, I think it's the one that would trip me up the most. I think the safety net here would be dead code elimination: `unused()` should be detected as never called and removed during compilation/transpilation so that this wouldn't be an issue. I am sort of surprised that `unused` is not picked up by the garbage collector in the first place though. Since JS functions are objects, shouldn't…

The fix is to implement the closures properly, by only closing over individual variable slots. It looks like the engines are implementing closures by closing over entire windows of slots--that is, if two functions have the same scope, they inherit the _union_ of the variables they reference as a single window/block of variable slots.

The original article has a much simpler explanation and solution: https://blog.meteor.com/an-interesting-kind-of-javascript-me...

To learn more about closures than you ever thought possible, try reading this paper describing how closures are implemented in Lua: http://www.cs.tufts.edu/~nr/cs257/archive/roberto-ierusalims...

Post reply on HN