rjvm

IIUC this should be fine - MemoryChunk doesn't seem to deallocate the memory (so we leak), unless there's a dealloc somewhere (sorry, not logged in to GH so cannot search). Which is not the worst outcome here, because as you said, we don't want to deallocate this memory since there may be places that still refer to it... 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...

Your understanding of Rust is correct, but the code uses unsafe: https://github.com/andreabergia/rjvm/blob/93e7e48db085e780b0... 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.

EDIT: Looks like this is not an issue because the invariant lifetime 'a is not used for the mutable reference of vm or call_stack. So it's not the invariance that is the problem, but rather how Rust reasons about the lifetime of mutable references, which this avoids. In that case I don't understand what the point of 'a is on VM and CallStack. You can create[1][2] those with any unbounded lifetime (including 'static[3]), which means it is not constraining anything. What is the lifetime 'a doing here? Why not remove it? [1] https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879... [2] https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879... [3] https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879...

Seems like that would take care of roots for the bytecode's themselves, but not for "native" functions[1]. Allocating a new object could call gc[2], and native functions are using the native callstack. It seems like it would be easy to allocate in a native function and any unrooted references would be invalidated. In fact I see a case like that here[3]. That method creates a reference with `expect_concrete_object_at` and then calls gc with `new_java_lang_class_object`. It avoids UB by not using `arg` after the call that gc's, but there is nothing stopping you from using `arg` again (and having an invalid reference). [1] https://github.com/andreabergia/rjvm/blob/main/vm/src/native... [2] https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879... [3] https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879...

I have a few questions about the garbage collection. One of the hard parts of implementing a garbage collector is making sure everything is properly rooted (especially with a moving collector). you have the `do_garbage_collection` method marked unsafe[1], but don't explain what the calling code needs to do to ensure it is safe to call. How do you ensure all references to the heap are rooted? This is not a trivial problem[2][3][4]. Also note that I cloned the repo and tried to run `cargo test` every test fails with 'should be able to add entries to the classpath: InvalidEntry(".../vm/rt.jar")' vm/tests/integration/real_code_tests.rs:15:10 [1] https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879... [2] https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe... [3] https://without.boats/blog/shifgrethor-iii/ [4] https://coredump