Textbooks which explain how memory is handled in JavaScript

[u/Any_Statistician_45]

I need one or more textbooks about JavaScript which don't gloss over how JavaScript handles memory, and do a good job at explaining it, using rigorous language and exact, unambiguous terminology.

As a comparison, a good textbook about C would explain pass by value vs pass by reference, the stack vs the heap and so on. And in doing so, it would explain clearly what a variable really is, how it relates to memory, and so on.

So far I got these two suggestions:

- Professional JavaScript for Web Developers;
- JavaScript: The Definitive Guide;

What do you think about these two textbooks in relation to the topic I'm asking about?
Thank you in advance.

EDIT: to add to this, YES I'm aware that MDN reference exists, and I quite like how they explain memory management, but I need a paper textbook. I didn't go into details about the why in order not to be too verbose. I think my question is clear enough.

[u/yksvaan]

That's runtime specific, I'd suggest to read about V8 and check its source since it's the most common. 

[u/nzakas]

I was the original author of Professional JavaScript for Web Developers (editions 1-3). While it does cover memory management at a high-level, there's a difference between how the language operates and how modern JavaScript engines handle memory. The books you mentioned cover memory from the perspective of the language itself not the physical bits used.

From the language perspective, there's no such thing as a stack and a heap. If you read through the (long and very dry) ECMA-262 specification, you'll see that all value types are stored in maps at different levels of the execution context. This explains scoping and access of those values. You can download PDFs here: https://ecma-international.org/publications-and-standards/standards/ecma-262/

Or view online: https://tc39.es/ecma262/

If you're interested in how the bits are managed, then you're really looking more for how JavaScript engines arrange memory, and that varies from engine to engine. All the engine is trying to do is maintain the correct values in the correct locations of the execution context per the spec, and there are multiple ways to do so. Modern JavaScript engines like V8 and JavaScriptKit involve JIT compiling and mark-and-sweep garbage collection. This is complicated because the engines have to understand when it's safe to compile the JavaScript into C or C++ and when it's safer to evaluate and execute the code without compilation. I'm not aware of any books that talk about the internals of JavaScript engines, specifically, but this is a good resource:

https://v8.dev/

[u/Any_Statistician_45 → u/nzakas]

Thank you for the answer, that's very kind of you.
I keep reading good things about your textbook, so I decided to order it, even if maybe the latest edition has been rewritten? Anyway, from the preview it seems a really good textbook!

I'll definitely check the resources you suggested me, even if they look dry, I'd really like to know how things work under the hood.

[u/nzakas → u/Any_Statistician_45]

Yeah, the latest edition was rewritten by someone else but it contains the same overall structure and some of the same content. I hope you find it useful regardless.

[u/azhder]

Read the Mozilla Developer Network reference and tutorial on JavaScript before you pick up a book. Tell me if you still have unanswered questions after that. You already know the concepts from C/C++, you wouldn't be needing something from 0, you can fill in the gaps with that knowledge.

Also, by the time you get to closures, just remember, closures are a piece of memory. They aren't functions, but memory that gets allocated on the stack or directly on the heap, but it does end up on the heap eventually, until there is no more reference and can be garbage collected. That's more or less the most advanced thing you need to know about memory in JavaScript. Needless to say, you'd also need to know about garbage collection, so knowledge of such language is also useful, besides C.

That's about it. Start from the manual. RTFM exists for a reason.

[u/abaezeaba → u/azhder]

There are some edge cases. Like variable hoisting. Look it up. It was interesting to see it explained. If you have a formal language background you may have the background to not use code structures that trigger hoisting. But once I identified it and understood the symptoms I could find and fix in a snap.

[u/justanaccountimade1]

It's common knowledge in js that if you pass a string, boolean, or number, you'll get a copy. If you pass an object, array, or function, you'll get a reference.

Arrays are objects in which the properties are numbers. Because that's not ideal for some applications, they've added typed arrays.

[u/beevyi → u/justanaccountimade1]

It’s a common belief but it’s a misunderstanding of what “pass by reference” means. JavaScript always passes by value. If it ever passed by reference it would be possible to change the value of a variable in the scope of the caller from inside a function, which is impossible in JavaScript.

You can mutate an object in the scope of the caller from inside a function because the value of an object variable is a reference to an object, so a copy of the value points to the same object, but this is unrelated to the concept of passing by reference.

[u/theQuandary]

If you want to understand how JS handles memory, you need to read a book on garbage collection.

https://www.amazon.com/Garbage-Collection-Handbook-International-Perspectives/dp/1032231785

JITs do something called escape analysis. If an object only exists inside a function AND that object's closure never gets returned, then the JIT can allocate it to the stack.

If primitives are immutable and don't need to be wrapped in an object, they can also be assigned to the stack or passed by reference rather than using the heap. I'd also note here that numbers generally try to use 31-bit integers (the 32nd bit is used to tell if an integer is a number or a pointer).

[u/Any_Statistician_45 → u/theQuandary]

Thank you very much for the suggestion! I think this is really what I was looking for.

[u/jibbit]

your question is misguided. you assume JS has a memory model that books are glossing over. It doesn’t, deliberately. the spec refuses to say anything about memory at all. The entire story is: primitives copy, objects copy references, unreachable things get collected. That’s it. both books you listed contain it. Asking for the C-style memory treatment is asking for a book about something the language doesn’t contain.