5 ms·
A JVM in Rust part 5 – Executing instructions
- FrustratedMonky 3y agoSo can we have a JVM written in Rust, running on WASM, running some Java, running MineCraft?
- airstrike 3y agoonly if that MineCraft runs Terraria running Pong
- worrycue 3y agoTake it full circle. Minecraft running Terraria emulating a 32-bit RISC-V CPU running Pong written in Rust - someone already did the latter part I believe, https://youtu.be/zXPiqk0-zDY?si=M0IHSzRLkaddwwKC https://youtu.be/zXPiqk0-zDY?si=M0IHSzRLkaddwwKC
- airstrike 3y agohaha yeah, I saw that last week! so incredibly cool
- FrustratedMonky 3y agoThank You. I had not seen that. It was incredible.
- bhawks 3y agoWith Minecraft simulating a 8bit games - https://www.pcworld.com/article/559794/8-bit-computer-processor-built-in-minecraft-can-run-its-own-games.html https://www.pcworld.com/article/559794/8-bit-computer-proces...
- deleted 3y ago[deleted]
- tracker1 3y agoPretty interesting to see the progress on this. Wonder if any of the JVM devs are looking at this, and curious how far it will progress.
- whizzter 3y agoMaybe they bookmarked to see if there'll appear fun stuff later, it's still pretty much in the gruntwork phase of adding definitions/loading/basic interpretation to Rust. (Not working on any official projects myself but the experiments I did was in C or Java itself and with the latter you get tools like ASM doing gruntwork quickly) One funny/annoying part of implementing a Java runtime is that you want mostly coherent handling of basic classes like Object, Class, String,etc.. (don't want tons of special cases in a JIT,etc) but the reflection data that defines Object and Class contains String's (That inherits from Object for a fun circular dependency). For the most complete runtime I did (supported basic reflection,etc) I went with faux-object's,strings,etc when starting up created from C definitions that mirrored the real object shapes and then once far into loading walked the heap to modify the faux-objects to point the vtables to the actually loaded types for those classes.
- fleventynine 3y agoMany of the safety benefits of Rust disappear once you start JITing machine code and jumping to it...
- nvm0n2 3y agoWhy would they? The direction for safer JVM research is to implement JVMs in Java, which has the advantage of being both memory safe outside a few tiny core areas (same as rust) whilst having cleaner code than the Rust impl (none of these problems with lifetimes). See here: https://github.com/oracle/graal/tree/master/substratevm/src https://github.com/oracle/graal/tree/master/substratevm/src
- bialpio 3y agoRust noob here so please be gentle - can someone explain why in `Vm<'a>` the lifetime is needed? I see that in tests, `Vm<'static>` gets created, presumably because there's nowhere to grab a better lifetime from? But if that's the case, would it be possible to express this in a different way? ISTM that Vm owns everything it needs, so is there a way to avoid bubbling the lifetime up? Similar question applies to ClassManager - it already owns all the classes (they are in an arena), so it looks like a lifetime is needed because there's no way to say "things live as long as ClassManager lives" w/o introducing the lifetime at `ClassManager<'a>` level...
- andreabergia 3y agoThe problem arises by the fact that `Class` needs to refer to other classes: pub struct Class<'a> { pub superclass: Option<ClassRef<'a>>, } pub type ClassRef<'a> = &'a Class<'a>; Given that classes are managed by the arena, I know the reference will not be dangling thanks to the 'a lifetime. Initially I had implemented this with raw pointers, without lifetimes, but then I switched to the reference because it felt more "idiomatic" and I had to put the lifetimes just about everywhere to make the compiler happy. If there are better ways to do this, I would be really happy to learn, though!
- bialpio 3y agoYeah, I think I understand why you had to write it this way, but the fact that this lifetime needs to be bubbled up so far up is really non-intuitive to me. > If there are better ways to do this, I would be really happy to learn, though! Me, too. :) I find myself limited by my way of thinking here, coming from C++ ("I _know_ it lives long enough, why don't you let me express this?").
- andreabergia 3y agoAgreed, it _is_ annoying. It bubbles up everywhere and it feels like "something to silence the compiler" more than "something to express the safety of the code", as other people have pointed out.
- hnarn 3y agoFrom the first post in the series: > I am very happy with what I have learned, about Rust and about how to implement a virtual machine. In particular, I am super happy about having implemented a real, working, garbage collector. It’s quite mediocre, but it’s mine and I love it. Given that I have achieved what I set out to do originally, I have decided to stop the project here. I know there are bugs, but I do not plan to fix them. Toy projects are fine, but I just think this should be pointed out clearly that this is not a serious, ongoing project.
- andreabergia 3y agoWell, I think it is written rather clearly in the first blog post of the series and in the github readme, whose second line is: > Important note: this is a hobby project, built for fun and for learning purposes. I am not going to repeat that in every part of the series. :-)
- deleted 3y ago[deleted]
- unwind 3y agoNice and detailed, thanks! As a struggling Rust n00b it's instructive with these kinds of walk-throughs. Found a typo: "[...] and the program counter will be implemented." -- the last word qouted should be "incremented", right?
- andreabergia 3y agoThanks, fixed!
- skitter 3y agoWhen storing an object in an array, the value is checked to be a Value::Object (which can't be null), but you also have Value::Null, so storing null in an array fails (I think). Storing null in local variables, a static field or an instance field works fine.
- andreabergia 3y agoGood point. Someone (probably you) opened a GitHub issue about this too. I might actually fix this one :-)