Hacker News Reader

Comment by bastawhiz | Hacker News Reader

I'm curious if the runtime flag to enable JITless mode could also be enabled at compile time, removing the JIT compiler from the binary entirely. That could be really useful for projects where memory comes at a premium (and performance is not a major concern), like micropython but for JavaScript.

I assume this also doesn't support WASM when the JIT is disabled (or rather, when you can't write to executable memory), but if it did it could be a neat way to write decently performant software for tiny systems with just some JavaScript "glue".

View on HN

> I'm curious if the runtime flag to enable JITless mode could also be enabled at compile time, removing the JIT compiler from the binary entirely. That could be really useful for projects where memory comes at a premium (and performance is not a major concern), like micropython but for JavaScript.

Theoretically yes, but this is not implemented. It should not be too hard to drastically reduce binary size with a build-time flag.

> I assume this also doesn't support WASM when the JIT is disabled (or rather, when you can't write to executable memory), but if it did it could be a neat way to write decently performant software for tiny systems with just some JavaScript "glue".

Correct, wasm is currently unsupported. Interpreted wasm is possible in the future, but would likely be very slow.

> It should not be too hard to drastically reduce binary size with a build-time flag.

And then how portable would the code be? Would this be a path to running node on CPUs without JIT support? Or does it still have to mess with the calling convention at an assembly level?

According to another comment in this thread [1] the interpreter is actually generated by the JIT at compile time so no, this wouldn't let you run V8 on a CPU that isn't currently supported.

[1] https://news.ycombinator.com/item?id=19379305

In JSC it's guarded by compile time, runtime, and iOS OS enforcement.

Reply on news.ycombinator.com