Rusty Java - Transition the Java Runtime from C/C++ to Rust.

Kennke, Roman rkennke at amazon.de
Wed Nov 20 17:52:47 UTC 2024


>> 
>>    If we're translating the Java runtime into a better language, that
>>    language would be Java.
>> 
>> 
>> Although rewriting HotSpot in Java would be equally hard work, it would
>> be much more rewarding and interesting.
> Having worked on two Java-in-Java VMs (JikesRVM and SubstrateVM -- oh
> and also a Lisp-in-Lisp OS i.e. Interlisp-D) I can agree to the
> interesting but I'm much less sanguine about the 'rewarding'.
> 
> There are many aspects of how pure Java operates that make implementing
> Java in Java a significant challenge. You end up having to allow some
> smaller or larger subset of the language to be 'impure', i.e. get
> substituted/compiled specially so it is not actually operating like Java
> code in one way or another. That's necessary in in order to be able to
> perform operations that are not constrained by the the Java's highly
> opinionated and deliberately constrained memory model, threading and
> synchonization model, etc. You also still need to pirate on native
> libraries to do things like i/o (unless you relish writing things like
> device drivers, file system management, etc in Java -- can be done, just
> as it was with Interlisp-D, but pheweee!).
> 
> Once you concede that latter point you have to ponder where exactly it
> is best to draw the lines between Java code, code masquerading as Java
> code but compiled/translated as if it were something else and explicitly
> invoked foreign code. I actually think Hotspot makes a very good
> trade-off, implementing a lot of stuff in the JDK, providing various
> flavours of intrinsics and JVM callouts to sidestep some of the language
> limitations and using standardized foreign libraries to do a lot of the
> heavy lifting.
> 
> Also, now that we have a JPMS we can maintain those boundaries very
> flexibly, redrawing the line to accommodate to new hardware, new
> libraries and new language features (e.g. as was done with method
> handles). It does not really do to be absolutist here.


I agree with all that you said.

Plus, we should not forget the cost-benefit equation: HotSpot is a *huge* code base with dozens or more engineers having poured more than quarter century of work into it. Rewriting this in Rust or any other language would be a prohibitively expensive undertaking, with comparably little benefit, IMO.

I might like the idea to write *new* components in Rust, or replace certain subsystems with new implementations when it makes sense, and if we can figure out how to interface between the C++ and Rust parts. It has actually already been done before. IIRC, the research group around Steve Blackburn wrote a new (research-y) HotSpot GC entirely in Rust.

Roman




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597



More information about the discuss mailing list