ffi underspecified about validator HOT 7 CLOSED

Is it possible for JS objects to cross the FFI boundary?

No, in asm.js code there are just ints and doubles basically. No JS objects at all. That's how it is possible to avoid all possible causes of bailouts. So likely for a compiler that generates JS objects like yours, asm.js isn't directly relevant, except perhaps for library code.

(This doesn't mean C# can't use asm.js though, an AOT might generate C or LLVM IR and be compiled to asm.js.)

from validator.

I was assuming it could operate at the function level where as long as a function only interacts with ints and floats and things that live in typed arrays, it can "use asm". It sounds like the entire application has to "use asm", then?

EDIT: I don't understand how JS objects crossing the FFI causes bailouts. I can understand how interacting with JS objects would cause bailouts. Why can't they have the semantics of void *? Is it because the GC rooting can cause bailouts?

from validator.

You can do "use asm" in a function scope, but lots of little asms won't be a good idea probably, the ffi path is not fast.

JS objects crossing ffi don't cause bailouts. JS objects in general cause bailouts. If you don't know at every point that no variable is a JS object, then you need to check a lot more stuff and possibly deoptimize. asm code avoids that.

from validator.

Btw, all of this is still a work in progress, don't take anything i said as a final answer. But what I said is true of the prototype implementation so far.

from validator.

In the example you have this. It would be good to explain why the sign must be forced etc.

        log(x|0);     // call into FFI -- must force the sign
        log(y);       // call into FFI -- already know it's a double

from validator.

The assumption in asm.js variables is that they are 32-bit values, neither signed nor unsigned. This makes it very easy to optimize them. But it also means that when the sign matters - like when calling an ffi - you must specify the sign.

Put another way, inside asm.js, variables have no sign, operations determine the sign (again, to make it easy to optimize). When going outside of asm.js, you need to specify the sign because a concrete value is being sent into JS, not just 32 bits of uncertain interpretation.

from validator.

I think FFIs are fully specified now (it is well-defined exactly what you can pass to them and get from them).

from validator.