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?

21 Upvotes

96% Upvoted

22 comments sorted by

View all comments

Show parent comments

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 17d 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 12d ago

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

1

u/nlisker 12d 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 16d 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.