Missed opportunity to call it Just
[deleted]
I have written a JVM in Rust
41–50 of 185 posts
Re: I have written a JVM in Rust
#42Earlier quoted context omitted.
Seems… redundant, no?
"The goal of Metascala is to create a platform to experiment with the JVM: a 3000 line JVM written in Scala is probably much more approachable than the 1,000,000 lines of C/C++ " Seems like a reasonable goal.
I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.
Re: I have written a JVM in Rust
#43Earlier quoted context omitted.
I think op meant "String literals". For those the spec seems to require interning: > Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern. And later: > Literal strings within different classes in di…
Thanks, makes sense yes. Still if the JVM look up in all cases defers to value after ref mismatch, it should work identically, no? Even if interning is mandatory as per spec, I'm not sure how it'd change the outcome of evaluation.
The problem is that, per the spec, the following must hold:
if("abc" == "abc") { System.out.println("correct"); }
if(new String("abc") != new String("abc")) { System.out.println("correct"); }
Re: I have written a JVM in Rust
#44Earlier quoted context omitted.
"The goal of Metascala is to create a platform to experiment with the JVM: a 3000 line JVM written in Scala is probably much more approachable than the 1,000,000 lines of C/C++ " Seems like a reasonable goal.
I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.
He's not saying that. What he is saying is that are simple, non-production quality implementation in Scala is much more amenable to experimentation than a sophisticated, production-quality implementation in C++ that weighs in at 300x the LOC.
Re: I have written a JVM in Rust
#45Great learning project, I'm glad the author is having fun. Implementing a VM from scratch is a blast, and I have learned so much in the past doing that kind of thing. If they're interested in bolting on a GC, it couldn't hurt to look at MMtk. ( https://www.mmtk.io/ ) Some high quality collection algorithms, written to be pluggable to various VMs, and written in Rust.
Note that MMTK is x86 only. I was going to use it for a toy project but I have a Mac.
Re: I have written a JVM in Rust
#46Earlier quoted context omitted.
"The goal of Metascala is to create a platform to experiment with the JVM: a 3000 line JVM written in Scala is probably much more approachable than the 1,000,000 lines of C/C++ " Seems like a reasonable goal.
I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.
I'm sure it's not complete, but I also wouldn't be surprised if 99% of what's in HotSpot is optimization tweaks and performance boosts which aren't essential to the JLS.
Re: I have written a JVM in Rust
#47Earlier quoted context omitted.
Also https://github.com/lihaoyi/Metascala for a JVM implemented in Scala running on the JVM.
Seems… redundant, no?
Nope. For a more realistic example of such a JVM, look at SubstrateVM (written in "SystemJava" and compiled to native code ahead of time along with the app it runs), and "Java on Truffle" (a.k.a. Espresso), which is a JVM written in Java designed to be compiled to run on top of SubstrateVM. Both projects are a part of Graal.
The reason to do this, beyond the inherently neat Inception factor, is that JVMs are a PITA to work on because they're normally written in languages like C++ or Rust which optimize for performance and manual control over productivity. That makes it hard to experiment with new JVM features or changed semantics. If you could write a JVM in a high level very productive language like Java (or Kotlin or Scala) then the productivity of people writing and experimenting with JVMs would go up. It would also make it feasible for "ordinary" Java devs to actually fork the JVM and modify it to better suit their app, at least in some cases.
There's also something conceptually cleaner about having a language and its runtime implemented purely in itself. As long as you don't mind the circularity, that is.
Espresso for example has hot-swap features HotSpot doesn't have, so you can modify your program as it's running in more flexible ways than what regular Java allows.
Re: I have written a JVM in Rust
#48Missed opportunity to call it Just
Just is already 'taken' in the Rust community as it is a command runner utility like make: https://github.com/casey/just
Re: I have written a JVM in Rust
#49I am curious if your ran into limitations due to the lifetimes on this signature
fn execute_instruction( &mut self, vm: &mut Vm, call_stack: &mut CallStack, instruction: Instruction, ) -> Result, MethodCallFailed>
When I try to add a lifetime to the `Err` variant of a `Result` and that lifetime is invariant (which it is due to `vm` and `call_stack`) it usually means that I can't use the question mark operator or have early returns in the code[1]. This makes error handling more verbose and less readable. Is that your experience as well?
[1] https://users.rust-lang.org/t/nll-and-early-return-not-allow...
Re: I have written a JVM in Rust
#50Earlier quoted context omitted.
I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.
He's not saying that. What he is saying is that are simple, non-production quality implementation in Scala is much more amenable to experimentation than a sophisticated, production-quality implementation in C++ that weighs in at 300x the LOC.
But a simple non-production quality implementation in C++ would also be amenable to experimentation and not have the bootstrapping issues as well as provide an easier starting point to incorporate more of the existing optimizations as desired.