A JVM in Rust part 5 – Executing instructions(andreabergia.com) |
A JVM in Rust part 5 – Executing instructions(andreabergia.com) |
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...
pub struct Class<'a> {
pub superclass: Option<ClassRef<'a>>,
}
pub type ClassRef<'a> = &'a Class<'a>;
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!
Of course there is a good chance that you will eventually want a VM-scoped lifetime for something else so maybe it is best to just start now.
> 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?").
If you are building one off trees such as for parsing and ast transforms, bumpalo is your friend.
In your case, you can look into generational arenas and slabs which are useful for graphs.
Found a typo: "[...] and the program counter will be implemented." -- the last word qouted should be "incremented", right?
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.
See here: https://github.com/oracle/graal/tree/master/substratevm/src
I might actually fix this one :-)
> 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.
> 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. :-)
As a result, when the VM gets dropped, the memory gets deallocated even if there are still objects that reference it.
Somewhat related, there also is the issue that when you create multiple VMs, you can use classes/objects/… created by one VM with another.
As for where the static lifetime gets into play, VM creation doesn't use unsafe & compiler is happy about it, even though ISTM that there could be a tighter bound on the lifetime? https://github.com/andreabergia/rjvm/blob/93e7e48db085e780b0...
The thing with a tighter bound on the lifetime is that VM carrying a lifetime for itself is fundamentally flawed. A solution would be to remove said lifetime, and have all methods on VM that return lifetimed objects take said lifetime from the reference to the VM.
I am not sure I am going to try it though - it probably is a bit too much code to change for something that I consider "done" and I am not working on. :)