4 ms·
Interesting decision. The architecture sounds a little unusual: "The interpreter itself consists of a set of bytecode handler code snippets, each of which han
by gsg 11y ago
Interesting decision.
The architecture sounds a little unusual:
"The interpreter itself consists of a set of bytecode handler code snippets, each of which handles a specific bytecode and dispatches to the handler for the next bytecode. These bytecode handlers are written in a high level, machine architecture agnostic form of assembly code, as implemented by the RawMachineAssembler class and compiled by Turbofan"
It also seems as if all calls are mediated by code generated by the compiler, which has the advantage of avoiding the awkwardness of different calling conventions between native and bytecode functions (possibly at some cost to performance?).
Fascinating reading. Thanks V8 people for allowing such documents to be public!
- barrkel 11y agoThe architecture is a threaded interpreter, a fairly old and not particularly unusual interpretation technique. https://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Threaded_code When written in C, is typically done using GCC's computed goto and the && label address-of operator extension. Writing the handlers in machine-agnostic assembly is interesting; I'm guessing they want to tune the output more than writing the handlers in C would let them, or they can't rely on something like GCC's computed gotos.
- yoklov 11y agoThere's a post by Mike Pall, author of LuaJIT, which explains why writing C is very suboptimal for maximally performant VMs: http://article.gmane.org/gmane.comp.lang.lua.general/75426 http://article.gmane.org/gmane.comp.lang.lua.general/75426 Worth noting that IIRC, for a while LuaJIT in interpreted mode was able to beat V8 in optimized mode not all that infrequently (although it depended on the use case, they are different languages, and I do not know if this is still the case).
- mraleph 11y ago> Worth noting that IIRC, for a while LuaJIT in interpreted mode was able to beat V8 in optimized mode not all that infrequently V8 had no optimizing compiler when Mike Pall sent his (in)famous mail about "LuaJIT interpreter beating V8 compiler"[1]. Also usual disclaimers about cross-language benchmarks apply (e.g. nobody looked how those benchmarks differ between JS and Lua implementation). [1] http://lua-users.org/lists/lua-l/2010-03/msg00305.html http://lua-users.org/lists/lua-l/2010-03/msg00305.html
- barrkel 11y agoCommon register allocation across different bytecode interpretation sequences was one of the things specifically on my mind that could be tuned using a high-level assembler. Very suboptimal might be a slight overstatement. I can see a way, given known register calling conventions, that you could write an interpreter written as tail calls and post-process the machine code to effectively JMP instead of CALL. Guaranteed tail calls would save you a bunch of effort, and register calling convention would give you some guarantees about consistent allocation.
- gsnedders 11y agoIt really reminds me of JavaSciptCore's LLINT.
- mike_hearn 11y agoNot that unusual. In fact the planned architecture sounds exactly like HotSpot: a fast assembly based interpreter that profiles the code, with tiered fast/slow compilers producing machine code for hot spots, with deoptimization support to allow more speculative optimisations. It actually seems a bit of a shame that V8 and Nashorn are competing despite heading towards very similar architectures.
- vitalyd 11y agoI got the same impression from a cursory read. Profiling in the interpreter has its downsides, chief among them is lack of inlining causing profiles sometimes to be less useful. Tiered compilation can help here, but requires more careful code cache management.
- gsg 11y agoHaving TurboFan compile the interpreter from machine-independent templates is what struck me as unusual. The rest is familiar enough, true.
- mike_hearn 11y agoThe HotSpot interpreter is done the same way, I believe. It's also a template based interpreter.