3 ms·

Graal/Truffle languages can support sandboxing and GraalJS does. So it's designed to run untrusted code. I think in this specific case it's really hard to say.

Graal/Truffle languages can support sandboxing and GraalJS does. So it's designed to run untrusted code. I think in this specific case it's really hard to say. It's sort of on the borderline. But we can imagine many other closely related cases where the higher level abstraction would help. You could potentially do something like Truffle with C++ and LLVM, but I don't think it'd be easy. The grain of the language works against you. It's interesting if V8 already has added some of the infrastructure necessary.

vlovich123 3y ago
You'd be surprised how much friction you'd have for C++ reflection. First, since it's a custom build step, you can do a mix of custom code gen and C++ constexpr/consteval for static reflection. Here's a header-only implementation for adding compile time reflection purely within the language [1]. And v8 already does dynamic code gen as part of its build process (to generate the snapshot to speedup instantiation of the isolate). Some amount of dynamic reflection is also a must since JS is a dynamic language with reflection support + you need to walk the GC tree. Of course none of this necessarily exists within the compiler part of the codebase as it's unlikely to be needed there, but clearly doable. I don't know the specific details of reflection needed for the abstractions you reference and clearly V8 is still doing some amount of manual IR generation, so it's possible it would be a substantial investment to actually retrofit those techniques into v8 (+ the current capabilities may exist in the wrong part of the codebase for applying it to the JIT itself). One would have to do a careful analysis of historical security exploits & specific techniques and their ability to prevent to figure out if it's worth adding those abstractions (especially since there is a potential performance tradeoff as you mention). As I said, I think there's insufficient research in this area to establish a compelling body of best practices (not to take away from the contributions of the GraalJS team to this space). [1] https://github.com/veselink1/refl-cpp https://github.com/veselink1/refl-cpp

vlovich123 3y ago

You'd be surprised how much friction you'd have for C++ reflection. First, since it's a custom build step, you can do a mix of custom code gen and C++ constexpr/consteval for static reflection. Here's a header-only implementation for adding compile time reflection purely within the language [1]. And v8 already does dynamic code gen as part of its build process (to generate the snapshot to speedup instantiation of the isolate). Some amount of dynamic reflection is also a must since JS is a dynamic language with reflection support + you need to walk the GC tree. Of course none of this necessarily exists within the compiler part of the codebase as it's unlikely to be needed there, but clearly doable. I don't know the specific details of reflection needed for the abstractions you reference and clearly V8 is still doing some amount of manual IR generation, so it's possible it would be a substantial investment to actually retrofit those techniques into v8 (+ the current capabilities may exist in the wrong part of the codebase for applying it to the JIT itself). One would have to do a careful analysis of historical security exploits & specific techniques and their ability to prevent to figure out if it's worth adding those abstractions (especially since there is a potential performance tradeoff as you mention). As I said, I think there's insufficient research in this area to establish a compelling body of best practices (not to take away from the contributions of the GraalJS team to this space). [1] https://github.com/veselink1/refl-cpp https://github.com/veselink1/refl-cpp