Hacker News Reader

Comment by im3w1l | Hacker News Reader

Yeah I got that far but then I wasn't sure what exactly that was doing. Normal C++ doesn't directly move stack pointers around and do manual probing, so I was idly wondering whether those calls hid some inline assembly or how they worked.

Edit: Or perhaps that is not the stack of the C++ program but rather than stack of the Javascript program.

View on HN

In general, there's no difference between the stack of the C++ program and the stack of the JS program. When SpiderMonkey just-in-time compiles a JS function, the result is native code that creates a stack frame on the same stack as the C++ code that implements SpiderMonkey. JS code and C++ code can be semi-arbitrarily interleaved on the stack: JS calls C++ calls JS calls C++...

The one exception about sharing the same stack is that the first few iterations of a function run in an interpreter implemented in C++, and that interpreter has its own stack that we heap-allocate. This particular bug occurred during the transition from the C++ interpreter to JIT code.

It does hide some assembly. Those calls are calling an assembler to generate native code at runtime for JIT compilation. The C++ compiler compiles an assembler, but this assembler runs at runtime. `MacroAssembler` itself is architecture independent, and calls into functions implemented in back-ends such as `MacroAssemblerARM` and `MacroAssemblerX64`.

So the code in this function is not performing the stack-probing, it generates code to perform it instead.

Reply on news.ycombinator.com