> 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…
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.
That is not yet clear. Early adopters have reported (jitless) V8 to be at least as fast as (jitless) JSC on Octane2 on a native iOS device.
A fast V8 with jitting isn't going away. Jitless V8 is meant for embedders that either cannot or do not want to allocate executable memory at runtime. (Also, in many common real-world workloads the performance…
I think that should be possible. The main restriction seems to be 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript. Using V8 to execute JS without 'browsing the web' sounds…
> 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…
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.
That is not yet clear. Early adopters have reported (jitless) V8 to be at least as fast as (jitless) JSC on Octane2 on a native iOS device.
A fast V8 with jitting isn't going away. Jitless V8 is meant for embedders that either cannot or do not want to allocate executable memory at runtime. (Also, in many common real-world workloads the performance…
I think that should be possible. The main restriction seems to be 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript. Using V8 to execute JS without 'browsing the web' sounds…