Javet Robustness

[priand]

We have a system that runs on the cloud and must not fail; it should be available 24/24. The JVM is pretty good at this, and we can even recover from OutOfMemory errors. Now Javet is native code, running in the Java process. What happens if it crashes for any reason? Older tests with J2V8 showed that it brutally exited the process, which we cannot afford. Does Javet have a different protection mechanism?

[caoccao]

Thank you for the questions.

Javet is very much robust so that many, many, many large companies have been using it in production for years.

1. Javet exposes quite some low-level API for Java applications to prevent OOM. E.g. NearHeapLimitCallback, Heap profiling API, etc.
2. Some companies sponsor me regularly so that they get premium support like design review, code review, crash dump analysis. I bet no one wants to analyze J2V8 crash dumps.

By the way, I'm not a fan of J2V8, so I designed Javet.

[priandsf]

Thank you for your reply!
I'm not a fan neither of J2V8 :-) But if you analyze crash dumps it is because they happen. It may simply due to a V8 bug.
So I'm wondering what the protection could be to prevent the whole JVM from crashing, if any could exist.

[caoccao]

So far I haven't seen any JS engines implemented in C++ not crash. The crash free world doesn't exist. It's more about how to address and fix it. Javet is heavily used in production where applications are supposed to run for months without a crash.

• Chrome / Node.js - You can easily crash Chrome / Node.js by typing [... new Array(1000000000).keys()] in the Console. But, Javet exposes a low-level API that can prevent this attack from crashing the application.

• GraalJS - God bless GraalJS users.

[priand]

Excellent - thank you for your feedback! I'll get deeper into it.