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

31–40 of 57 posts

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

#31

Post by gsnedders »

favorited wrote: post #28
IgorPartola wrote: post #5

Earlier quoted context omitted.

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…

I haven't done JS in a while, but it sounds to me like it is referenced, just not in source code. `someMethod` references it implicitly. Is my understanding correct?

Yes. The function's frame contains a reference to the object storing local variables of the parent frame. To do better you need to store a list of variables referenced (which you can only do if there's neither direct-eval nor a with statement).

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

#32

Post by Ajedi32 »

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…

> 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.

I don't know about Python, but for JavaScript can't you use the built-in devtools? Maybe try grabbing a heap snapshot, or recording a record allocation profile and go from there?

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

#34

Post by chasd00 »

Jach wrote: post #30
vvanders wrote: post #4

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

The particular memory issue is new to me (though now I can watch out for it, yay) but I'm not surprised... JS lacking proper lexical scope causes many issues.

when you say "proper lexical scope" do you mean just block vs function level scoping of variables? If so, i wouldn't say javascript is wrong it's just different.

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

#35

Post by phyllostachys »

randomguy1254 wrote: post #14

Nice article. Minor gripe about the static vs dynamic memory section. The requirement that the data sizes be known at compile-time for static memory (with the example of an array allocated to a user-inputted size), seems to be based on a past restriction of the C language. C has since remove the requirement that stack-based arrays are sized with a compile-time constant; there is nothing at the hardware/assembly level…

I was bothered by saying that static memory is assigned on the stack (implied that it is only on the stack). As an embedded guy, at least in bare metal situations, local function statics, any const variables, and any globals are either in the read-only data section[1] or in the general data section[2], both before the heap and definitely not in the stack section.

[1] - .rodata section in gcc

[2] - 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...

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

#36

Post by phyllostachys »

phyllostachys wrote: post #35
randomguy1254 wrote: post #14

Nice article. Minor gripe about the static vs dynamic memory section. The requirement that the data sizes be known at compile-time for static memory (with the example of an array allocated to a user-inputted size), seems to be based on a past restriction of the C language. C has since remove the requirement that stack-based arrays are sized with a compile-time constant; there is nothing at the hardware/assembly level…

I was bothered by saying that static memory is assigned on the stack (implied that it is only on the stack). As an embedded guy, at least in bare metal situations, local function statics, any const variables, and any globals are either in the read-only data section[1] or in the general data section[2], both before the heap and definitely not in the stack section. [1] - .rodata section in gcc [2] - I think this is in…

After looking at that default linker script dump, I noticed it didn't have the stuff I saw in the ARM linker script that I'm used to. So I attached one for a Silicon Labs EFM32 part. It's below the x86-64 linker script and is a little easier to read.

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

#37

Post by phyllostachys »

phyllostachys wrote: post #36
phyllostachys wrote: post #35

Earlier quoted context omitted.

I was bothered by saying that static memory is assigned on the stack (implied that it is only on the stack). As an embedded guy, at least in bare metal situations, local function statics, any const variables, and any globals are either in the read-only data section[1] or in the general data section[2], both before the heap and definitely not in the stack section. [1] - .rodata section in gcc [2] - I think this is in…

After looking at that default linker script dump, I noticed it didn't have the stuff I saw in the ARM linker script that I'm used to. So I attached one for a Silicon Labs EFM32 part. It's below the x86-64 linker script and is a little easier to read.

After a little investigation[1][2], it seems things get weird with an OS, as would be expected with virtual memory, et al.

[1] - https://stackoverflow.com/questions/16360620/find-out-whethe...

[2] - http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in...

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

#38

Post by randomguy1254 »

kahlonel wrote: post #25
randomguy1254 wrote: post #14

Nice article. Minor gripe about the static vs dynamic memory section. The requirement that the data sizes be known at compile-time for static memory (with the example of an array allocated to a user-inputted size), seems to be based on a past restriction of the C language. C has since remove the requirement that stack-based arrays are sized with a compile-time constant; there is nothing at the hardware/assembly level…

Except for the fact that the arrays you are talking about are still put on the stack.

Apologies if unclear, that is what I meant be stack-based. Article implies that you cannot create a dynamically sized object on the stack.

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

#39

Post by abritinthebay »

horsawlarway wrote: post #24
abritinthebay wrote: post #17

Earlier quoted context omitted.

Like I said - it's mostly arbitrary. ;) 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.

It's not that simple though. Most modern CPUs that support the x86_64 instruction set don't actually run them as instructions on the hardware. They do all sorts of magic to queue operations, increase pipeline throughput, manage register access, make branch predictions, etc... 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…

Ah interesting. Not familiar with x_64 really. Mostly 16 & 32 bit experience here.

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

#40

Post by barrkel »

Jach wrote: post #30
vvanders wrote: post #4

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

The particular memory issue is new to me (though now I can watch out for it, yay) but I'm not surprised... JS lacking proper lexical scope causes many issues.

Lexical scope is a semantics concern - observable behaviour that is required for correctness. The case under discussion is an implementation concern - there's no necessity for it to leak by creating a linked list of activation records as further analysis could break the chain. The two are not related.
Post reply on HN