WebKit uses a constraint-based garbage collector that does not rely on reachability alone. This is an improvement over the classical garbage collection algorithm.
 - .rodata section in gcc
 - I think this is in the .data and .bss sections, where .data is copied from the file and .bss is zero initialized before calling main by the crt. If you peak into a linker script, or dump one by passing --verbose to ld, you can even see where it puts all the C++ bits and pieces. A dump I did on Debian with g++ is here: https://gist.github.com/Phyllostachys/0682a3bda13ef9c6b49d04...
 - https://stackoverflow.com/questions/16360620/find-out-whethe...
 - http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in...
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 it detect an object that's not referenced during the mark and sweep?
In general, I really hate having to debug memory leaks in JS or Python. The interpreter for both will randomly allocate additional memory as it runs, so using tools like Valgrind is next to impossible. The only reliable method I've found is to pepper my code with logging statements that show what the current memory usage is, run the code like 1000-10,000 times, and see the points between which the memory usage goes up without coming down on a consistent basis. Python's built in `gc` module seems nearly useless for determining what's actually stuck in memory, and having a billion libraries that can have their own memory leaks is also not fun. These are the times I miss C: when you leak memory in C you know it because it becomes painful fast and it's usually easy to find, if your code is sane.
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...
Is my understanding correct?
Chrome bug report: http://crbug.com/315190
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's easier to have on context record instead of several.
Other languages do not do this. Off the top of my head: Lua, Java, Scala
Happy to report that no crash in Nightly.
Edit: No crash in Edge either.
Firefox and Edge won't crash, but you'll be using 3GB+.
Currently, the ECMAScript specification says nothing about GC.
And it seems every major JS engine has decided that this type of memory leak is okay.
So it's rather unlikely something will change.
e.g. Memory at the machine level,
I think it's the other way around --- their usual level of abstraction is too high to understand such things...
or type systems
...and slightly too low to understand others.
IMHO memory leaks are important only on embedded software because you start there with a really low memory available for your software to run.
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.
There I can happily create millions of short-lived objects before getting problems in a single-user application.
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.
However, I think it is fair that most people learn roughly what the side effects are of each line at a local level.
Ironically, this is an argument against many functional languages. There are not side effects of the logic, per se. However, there are massive implementation side effects that are not necessarily easy to reason on.
The saving grace for the vast majority of people is that typically you can get by without knowing all of this. The people that care, do care. But statistically you are not one of them. :)
That said I think the issues with assembly you mention aren't magic as such, they're just consequences of the commands. They don't really hide much (if anything) behind the scenes that you'd have access to anyhow.
It's just that CPUs do so much more than they used to.
You can think of assembly on those cpus as a high level language. It has little correlation with what's actually happening in hardware.
This is EXACTLY the same type of "magic" that is getting complained about above. The real implementation details are hidden and unknown, but the abstraction is useful.
I was just musing on how the arbitrary line is probably not as difficult to see as many other lines we have out there. I think this would fall into "systems languages" and related things.
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.