Comment by bodyfour | Hacker News Reader

Comment by bodyfour | Hacker News Reader

Parent Full thread

What would be the killer feature for me would be if I could select an interpreter-only mode... ideally at either compile-time or run-time.

The products I work on sometimes need to be deployed in environments where JIT code is disallowed due to security constraints. Now, I don't mind if my code runs dog-slow there, but it does still need to run.

Some projects that use JIT techniques work well in this scenario. For example pcre has an opt-in JIT, so at regex-compile time I can decide to stick with the non-JIT implementation and take a speed hit. Everything still works.

I know when V8 was new-ish the party line if you wanted a JITless version was to just have it target ARM and emulate the instruction stream. However I don't know if anyone ever implemented such a beast. It also would be ugly if you wanted to decide at runtime whether to JIT since I don't know how easily V8 can dual-target.

Anyway, if Ignition can run any V8 code maybe we can get an Ignition-only mode? It would also open up a path to running V8/node.js on CPUs that V8 can't target natively yet, albeit somewhat slowly.

An alternative would be to use an js engine like mozilla's (or a purely interpreted one like duktape) but the ecosystem (node and whatnot) seems to have settled on V8 so it definitely would be nice to be able to use.

Apologies if I'm talking nonsense and there's an easy way to do this now.. the last I looked at this problem in depth was pretty early in V8's life. I haven't heard any news about JITless operation though.

IIRC when they first announced Ignition, running in non-JIT environments was an explicit "non-goal".

I don't think that they are against it, but i'm assuming nobody is really trying to get that to work, and I think some code is still JIT-ed during ignitions normal operating, so getting a "pure" interpreter might be much more work.

Things might have changed since then, so someone with more up-to-date information will have to chime in if i'm horribly off.

But I do have issue with this:

>An alternative would be to use an js engine like mozilla's (or a purely interpreted one like duktape) but the ecosystem (node and whatnot) seems to have settled on V8 so it definitely would be nice to be able to use.

The ecosystem has not settled on V8 (hell I just started playing with espruino which is a javascript engine built to run on extremely low power devices like the ESP8266), and IMO it shouldn't ever settle on one implementation. Alternate engines keep the javascript ecosystem healthy. It prevents bugs in one from becoming a defacto standard, it promotes competition and specialization, and it's the way javascript standards become standard (IIRC something like 3 separate major implementations are needed).

Chakra is really giving V8 a run for it's money recently, and even javascriptcore is quickly catching up and is much better in areas like memory usage.

> so getting a "pure" interpreter might be much more work.

If that's the case I'd have to take their word for it.. it's their code so they know the pitfalls. It still surprises me though: if I was developing a feature like that it would be the first thing I'd want to get working so I could try all of my test cases on interpeter-only mode.

Maybe there are some types of code that the interpreter just can't handle and always fall back into the JIT?

> The ecosystem has not settled on V8

Sorry, I probably didn't express myself wall. I personally am excited about the development of other js engines, and I also home that continues.

For non-browser js, though, node is the 800lb gorilla. I'm hoping that the (apparently reborn?) Spidermonkey or node-chakracore really take off to the point they're first-class options for using with node. However, I am not sure if that will ever happen.

I personally think duktape gets a lot of things right with its lua-inspired API and easy portability. However, it will probably never have a JIT available.

I'm pretty sure they have a way to run in "Ignition only" mode, but Ignition still uses executable memory for some things, so an "Ignition only" mode is not a "JIT-free" mode.

You can enable or disable SpiderMonkey's various JITs in Firefox's about:config prefs. Try disabling all the JIT prefs and running some JS benchmarks to measure interpreter-only mode. :) Each JIT level is roughly 10x faster on my machine.

javascript.options.baselinejit controls the first-pass JIT.

javascript.options.ion controls the IonMonkey optimizing JIT.

javascript.options.asmjs controls the OdinMonkey asm.js JIT.

javascript.options.wasm and javascript.options.wasm_baselinejit controls new WASM JITs.

Yes last I checked you could still build firefox on platforms they didn't have a JIT for, so it certainly must be possible. Sadly, SpiderMoney isn't as commonly used for embedding compared to V8. Maybe Spidernode will take off in the node community and make it a more popular option... we'll see.

From watching the video it seems that Ignition is ~2x slower than JIT which sounds like great performance for a non-JIT'ed implementation.

Disallowing JIT due to security. That's something I'd like to understand. What might I Google?

iOS devices do that.

V8 recently introduced the flag --minimal which only uses Ignition. The intention behind the flag is to bootstrap porting though.

Reply on news.ycombinator.com