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

Wed Nov 20 19:54:32 UTC 2024

Thanks for the valuable feedback... but read until the end...

To be clear, this was not a case of Change for the sake of change. 
Rather I was inspired by Linux, Microsoft, DOD, and other swho I believe 
would not choose Rust for the sake of change. My intuition was, if these 
famous projects were investing in Rust, then the famous project of Java 
and the JVM might benefit from a similar investment. My intent was to 
open a discussion on these issues because I could not find previous 
discussion.

While I am not a Rust expert, I have played around with it enough to 
appreciate some of the important new thinking it integrates, and the 
reasons why I gave up on C/C++.

On 2024-11-20 11:07 AM, Jesper Wilhelmsson wrote:
> Hi Eric,
>
> As you probably already figured out, this is a no-go for so many 
> reasons. I'll just add another one on the pile for good luck.
>
> Even if we could just snap our fingers and have the perfect 
> translation of the JVM in rust, just ready to go, all tests passing, 
> drop in replacement in the src directory, we could still not do it.
That was never my intention. I don't know why you are assuming that.
>
> The JVM is developed and maintained by engineers who in many cases 
> have worked with C++ development for decades. They know the C++ 
> language, they know the JVM source code. Re-writing things in a 
> different language like rust would unavoidably change how things are 
> implemented, like synchronization/locking or gory details in the GC 
> implementation. There are things in the JVM internals that are built 
> the way they are because C++ works the way it does. Moving to a new 
> programming language would change how these things are implemented - 
> not only the syntax of the language, but the algorithms themselves as 
> well.
That is a good argument that I did not have insight on. Thank you.
>
> This means that not only would you have to teach all JVM developers 
> world wide a new programming language and new tools for development 
> and debugging that at least some of them have never seen before and 
> have no interest in learning, which in itself is a major and truly 
> expensive task, you would also loose all institutional knowledge these 
> developers have about how things in the JVM works after having worked 
> in the code base for decades.

My intention was an evolutionary change to the JVM. For example

    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

 From my understanding of Linux, they have been writing new drivers in 
Rust, similar to writing a new GC in Rust.

>
> Change for the sake of change is almost never a good idea. We 
> routinely say no to changes that cleans up code or make use of new 
> language features if they don't bring an actual benefit as well. 
> Cleaning up code that no one is working in is not really useful for 
> instance. Moving all code to a new language would change code that has 
> been running without bugs or changes for 20+ years. I started with the 
> assumption that we could do the translation perfectly without bugs, 
> but we all know that's not true. There will be bugs introduced all 
> over the place. New interesting bugs that will take years to weed out. 
> So unless your intention here is to destabilize the Java platform for 
> many years to come and force a large group of C++ developers to start 
> looking for a new job because they actually are C++ developers by 
> choice ...

I am personally offended by the remark, "So unless your intention here 
is to destabilize the Java platform for many years to come and force a 
large group of C++ developers to start looking for a new job because 
they actually are C++ developers by choice ..."

That is insulting, childish, and very unprofessional. Why would anyone 
ever intend such a thing?

>
> As all developers who suggest changes to the JDK should have done 
> already, I suggest you also read 
> https://openjdk.org/guide/#why-is-my-change-rejected
>
> /Jesper
>
>> On 20 Nov 2024, at 18:52, Kennke, Roman <rkennke at amazon.de> wrote:
>>
>>
>>>>
>>>>   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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20241120/898e903a/attachment.htm>