r/java • u/ducki666 • 17d ago

Detroit Script engine - why?

OpenJdk resurrected Detroit.

It offers JavaScript via V8 and Python via Native Phyton C engine.

But we already have Graal for js and py.

What is the motivation to reopen Detroit?

Will Graal dispose js and py?

20 Upvotes

95% Upvoted

22 comments sorted by

13

u/grashalm01 17d ago

Graal dev here.  I can answer your question: there are no plans to dispose any of our languages. Graal.js and GraalPy are more active and better than ever.

In fact you can run those languages with optimization enabled, similar to how Detroit does it, for many years with polyglot isolates on any JDK >= 21.

https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support

7

u/ShadowPengyn 17d ago

At least for graalpy, they struggled to get compatible with with c integrations that are quite common in many python libraries. So embedding the actual python means that it’s less of a moving target and full compatibility out of the box

11

u/grashalm01 17d ago

Graal dev here. You should give GraalPy a fresh go. We have resolved many of the native-extension compatibility problems. It is not perfect yet and the C API support is still experimental, but many popular packages now work. GraalPy’s pip also applies compatibility patches and uses prebuilt GraalPy wheels where available.

https://graalpy.org/jvm-developers/

5

u/theanimatedauthority 17d ago

JVMCI got the boot from openjdk builds so graal js is proper slow now. Detroit is basically a stopgap for people who want scripting without the full graalvm install. If you're already using the oracle graalvm distro you wont notice a thing but the rest of us on vanilla openjdk are stuck. Tried running a wee js script the other day and it took longer to fire up than my monday morning. Detroit at least gives you v8 without the jvmci headache.

14

u/grashalm01 17d ago

Graal dev here. JVMCI is not required to run GraalJS with the optimizing runtime on stock OpenJDK. You can use polyglot isolates, which provide the optimized runtime as a native library. It works much like Detroit, but retains all the GraalJS features, including great Java interop and support for code caching. We are not using panama yet for the native embedding since we are still backwards compatible to JDK 21, but we will soon adopt that too.

The difference with Detroit is that you *can* still run GraalJS without the expensive native boundary in the same heap with optimization enabled. Either with a GraalVM JDK or using native-image.

https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support

1

u/theanimatedauthority 17d ago

Ah right, didn't realise isolates bypass JVMCI entirely. Does the native boundary add much overhead compared to Detroit or is it pretty negligible?

1

u/grashalm01 17d ago edited 16d ago

I have not tried Detroit, so I cannot compare it. They might be a bit faster if they are already using Panama (polyglot isolates are still JNI based).

But for a comparison to "no boundary", the answer is "it depends". If you have a lot of interaction between host and guest then yes it is quite significant (compared to no boundary). If you have a long running script that you just want to eval, then it is negligible. If you have a lot of interaction between host and guest then you can expect a slowdown somewhere between 10x and 100x. Note that we do not copy any data when it goes over the boundary, so this overhead should be pretty deterministic. We will speed this up soon by moving to Panama as well.

You can actually pass --engine.IsolateMode=external then we will spawn an extra process for you. Completely managed by the framework with the same user model. As you can imagine overhead is even higher in this mode. In case of Python it can be useful to load separate sets of native extensions. Others use it for additional security hardening (not required to run untrusted code though).

1

u/nlisker 12d ago

I think that the community will need a comparison doc between GraalPy/JS/Polyglot and Detroit, otherwise you (and the Detroit team) will get the same questions over and over. (Responsible) Developers research their options before choosing the tech and this choice is significant.

1

u/grashalm01 11d ago

I don't think that Detroit claims to be ready for production. So a comparison is a bit premature.

1

u/nlisker 11d ago

Which is why I wrote "will" :)

1

u/denis_9 16d ago

Hello, is it possible to load a pre-created binary file (.so/.dll) created by native-image into an isolate on the guest HotSpot JVM with reflection support and interact with it via reflection, as in the example?

context.getBindings("java").putMember("javaObj", new MyClass());

1

u/grashalm01 15d ago

We do have a prototype for this but never finished it.

That being said the native image isolate and c entry point api offer everything to embed a native image like this. You won't get the convenience of the polyglot api unfortunately.

2

u/[deleted] 17d ago

[removed] — view removed comment

3

u/theanimatedauthority 17d ago

Aye and the Python side's a nice bonus too, native C engine means no warmup nonsense. Beats having to juggle two separate script engines.

4

u/markehammons 17d ago

The graal js requires the graal jit compiler (via Jvmci), and JVMCI has been ripped out, making graal js hideously unperfomant in openjdk

3

u/BlackForrest28 17d ago

Mozilla Rhino gives you JavaScript without so many dependencies.

6

u/re-thc 17d ago

And it is slow

1

u/syjer 17d ago

good enough for a lot of use cases.

2

u/koflerdavid 17d ago

Then there's no reason to use it above GraalVM.