Turbocall – Just-in-time compiler for Deno FFI • Hacker News Board

Re: Turbocall – Just-in-time compiler for Deno FFI

#11

Post by notnullorvoid » Tue, Mar 26, 2024, 12:30 AM UTC

diath wrote: post #4

Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?

As a heavy Node user, I think it was a mistake for Deno to try to bake in a compatibility layer with Node. It's a moving target, and will detract from other valuable work.

Node compatibility is not something that will get me to switch to Deno. I will switch once I'm not restricted to the bundled TSC version, and there is a well supported bundler for client code.

Re: Turbocall – Just-in-time compiler for Deno FFI

#12

Post by Retr0id » Tue, Mar 26, 2024, 3:23 AM UTC

chatmasta wrote: post #9

There have been a lot of security bugs in Chrome related to this layer of V8, most of them caused by some form of type confusion. Is there worry about increasing the size of Deno's attack surface by adding this capability?

JIT is a large attack surface, but it's mostly an attack surface from the perspective of migrating from "untrusted" (attacker-controlled) javascript execution, to arbitrary native code execution (e.g. malicious js on a webpage, breaking out).

If a Deno user wants to use FFI to invoke system("rm -rf /*"), they can*, and they don't need to exploit a JIT bug to do so.

FFI with JIT is almost certainly a larger attack surface than FFI without JIT, but in practice I don't think it's a big difference.

*iiuc Deno is sandboxed by default, so presumably FFI capabilities (and the attack surface implications thereof) are something the developer needs to opt into from the start.

Re: Turbocall – Just-in-time compiler for Deno FFI

#13

Post by pjmlp » Tue, Mar 26, 2024, 6:06 AM UTC

Kamq wrote: post #10

diath wrote: post #4

Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?

This is only one strategy to get adoption. The other is to have better apis/more features so that new projects gradually move to your runtime. In this hypothetical, eventually being on node would become like still being on java 8 is today.

Except node, like Java, moves along, making those that made a bet being a better Java 8, seem irrelevant with time, unless they happened to have a platform holder sponsoring their existence.

Deno needs a bit more than that for adoption.

Re: Turbocall – Just-in-time compiler for Deno FFI

#14

Post by irq-1 » Tue, Mar 26, 2024, 4:50 PM UTC

This only seems to speedup value functions (not struct/callback or other C functions.)

From the referenced file: https://source.chromium.org/chromium/chromium/src/+/main:v8/...

* Currently supported return types: * - void * - bool * - int32_t * - uint32_t * - float32_t * - float64_t * Currently supported argument types: * - pointer to an embedder type * - JavaScript array of primitive types * - bool * - int32_t * - uint32_t * - int64_t * - uint64_t * - float32_t * - float64_t