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. :-)