Hacker News Reader

Comment by cromwellian | Hacker News Reader

For very security sensitive embedded applications, this could be a huge boon, since it reduces attack area surface, both from the point of view of executable pages, to the simplicity of the interpreter vs full JIT. Granted, there are many JS interpreters already available, like Ducktape, that fulfill the same benefits, but the immediate upside of this is compatibility with the full Node/ES6+ ecosystem and Chrome Dev Tools.

I have to say, Ducktape looks like it might have superior resource usage for very low memory situations.

View on HN

> I have to say, Ducktape looks like it might have superior resource usage for very low memory situations.

Don't forget Moddable's XS, which does more with even less and just shipped ECMAScript 2019 (ES10) support.

http://blog.moddable.com/blog/es2019/

ChakraCore also has the ability to disable JIT. And we have a build configuration that compiles out the JIT so the binary is smaller as well.

I believe people in the community also have a ChakraCore fork specifically made for using Node on iOS.

Definitely agree duktape is a decent attempt at low memory situation, but one additional point is that duktape is very slow compared to modern JavaScript engines.

Hence I wonder if we can split ignition off v8 to create a standalone fast JavaScript interpreter at the cost of (possibly) more memory consumptions than duktape, that could prove to be useful in many scenarios.

“Very slow compared to” is still as fast, or faster than, many other dynamic language runtimes. In my case I saw a 2x-10x difference between V8 and Duktape, which is acceptable given the trade-offs.

Agreed, and I'm not saying duktape doesn't have a use case, I'm merely saying having a standalone ignition interpreter might enable different use cases.

Ignition is very tightly coupled to the rest of V8, starting with that fact that it uses inline caches and the object model to maintain performance, and finishing with it itself being written in "CSA", which is an assembler DSL that is passed through the TurboFan (optimizing compiler) backend to generate the machine code for the bytecode handlers (this has the interesting side-effect that porting V8 to a new platform requires porting the optimizing compiler). There's not really much that can be split off.

Thanks for the explanation! One follow-up question is: how can we still call ignition an interpreter with this flow where TurboFan is still used to generate machine code? Doesn't that defunct the idea of an interpreter in v8, which is to be used in platforms w/o write access to executable memory, such as iOS or PS4?

While bytecode handlers (and other builtins) are generated by TurboFan, this happens at V8-compile-time, not at runtime. Their generated code is shipped embedded into the binary as embedded builtins.

This suggests that a specialized app (such as a set-top box, smart TV, or game console) could push more code through the pre-JIT process to further close the performance gap. (This is interesting to me, because I haven’t seen much interest in pre-JIT compilation since the early days of Java, HotSpot, etc.)

I quite like Duktape because it is really simple to embed as well. The V8 API is comparitively pretty complicated.

I'd like to check that out. Unfortunately, like other projects that idiotically adopt a generic name that can't be Googled without returning an endless swamp of irrelevant results, I can't seem to find any info on "duct tape" as it relates to JavaScript interpreters. Any good pointers?

The use case in question: a few years ago I embedded V8 in a Win32 app with a single .DLL and header file, but V8 has exploded in complexity since then and no longer appears suitable for lightweight applications, meaning anything smaller than a full-fledged Web browser. I need to upgrade that interpreter at some point, so I'm definitely in the market for something comparable to what V8 used to be.

Kind of unfortunate, but I'm hardly the user the V8 team has in mind.

Google duktape, not duct tape.

For anyone that is interested, duktape ( https://www.duktape.org/ ).

The API docs are at https://www.duktape.org/api.html , it's a C API and it's pretty easy to work with and bind native code. I kinda wish that more JIT compiled languages had an API as nice as LuaJIT.

Thanks, that was the trick I was missing. Will have a look.

But is the increasing complexity (an interpreter added to the codebase) not introducing also another - new - attack vector?

The interpreter has always been part of the codebase since it is used during startup and while the code is still being JITed

Not always, actually. V8 came out in 2008 and didn't have an interpreter until 2016. For the first eight years, the non-optimization execution was also a JIT, just a simpler one.

IMHO, interpreters are simpler and easier to understand than optimizing JITs. Just look at the recent V8 range-check elimination bug around WASM optimizing +0 and -0 differently in a Math related intrinsic.

Reply on news.ycombinator.com