[shikon7]

> Although being written in Java does improve memory safety, we just saw that rewriting V8 in a safe language wouldn’t help with the types of bugs V8 is trying to solve and so we would intuitively expect that GraalJS must suffer from the same classes of bugs. Yet, it doesn’t.

Essentially it exchanges the bugs of a V8 engine for the bugs of the GraalVM, right?

[drysart]

That's what I got from reading the article; the takeaway is that all its doing to solve the types of problems V8 has is by shifting the complications beneath another layer. All the problems and challenges and potential for mistakes still exist, they're just within GraalVM now.

Which is not without real benefit, of course; it's a lot easier to build and secure one genericized VM runtime toolkit than it is to rebuild everything from scratch for every single language runtime like V8 that might need to exist. It's far better to competently solve the difficult problem once than to try to competently solve it over and over and over.

[anonymousDan]

Yeah I wonder if there has been much work on formal verification here (including of compiler passes). I know the LLVM team have done some interesting work on verifying LLVM passes using the Alive2 tool for example.

[mike_hearn]

No, that's not what it's arguing.

Basically it's easier to implement optimizations correctly if you're expressing them in regular logic instead of hand-written graph manipulations. The underlying approach is fundamentally different.