Memory safety does come with a price. It was ever thus.
It's competitive in some respects. It's not used in browsers so it's probably not competitive there where there are different code patterns to server-side JS (unless you want a security upgrade more than top performance), due indeed to the slower warmup time which really hurts in the web environment where code gets discarded regularly.
Also, V8 probably has better memory usage. I haven't checked.
The warmup time is being worked on but these are research problems, and the V8 team is much larger than the GraalJS team is.
> Memory safety does come with a price. It was ever thus.
The memory safety claim is about as fishy as the benchmarks.
I'd trust the JIT hardening of a modern JS engine over whatever hardening has happened in the OpenJDK any day of the week. In other words: if the JS engine was built on top of Truffle, then the exploit technique would be all about finding bugs in Truffle/Graal/OpenJDK. And I bet that's easier than finding bugs in V8 or any other JS engine, just because the JS engines have been fighting the security fire with extreme prejudice due to their security exposure and I doubt that the OpenJDK crew has had to since it's not as worth it to attack them. And if it was as worth it to attack them, then the complexity of the OpenJDK would make it an easier target to attack and a harder target to meaningfully lock down.
It's competitive in some respects. It's not used in browsers so it's probably not competitive there where there are different code patterns to server-side JS (unless you want a security upgrade more than top performance), due indeed to the slower warmup time which really hurts in the web environment where code gets discarded regularly.
Also, V8 probably has better memory usage. I haven't checked.
The warmup time is being worked on but these are research problems, and the V8 team is much larger than the GraalJS team is.