4 ms·
I am curious if your ran into limitations due to the lifetimes on this signature fn execute_instruction( &mut self, vm: &mut Vm<'a>, call_stack: &m
by celeritascelery 3y ago
I am curious if your ran into limitations due to the lifetimes on this signature
fn execute_instruction(
&mut self,
vm: &mut Vm<'a>,
call_stack: &mut CallStack<'a>,
instruction: Instruction,
) -> Result<InstructionCompleted<'a>, MethodCallFailed<'a>>
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-allowed/85937 https://users.rust-lang.org/t/nll-and-early-return-not-allow...
- celeritascelery 3y agoEDIT: 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/be9c54066c64a8287902553dc1bab4b94206086c/vm/src/call_stack.rs#L45-L47 https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879... [2] https://github.com/andreabergia/rjvm/blob/be9c54066c64a8287902553dc1bab4b94206086c/vm/src/vm.rs#L73 https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879... [3] https://github.com/andreabergia/rjvm/blob/be9c54066c64a8287902553dc1bab4b94206086c/vm/tests/integration/real_code_tests.rs#L10-L17 https://github.com/andreabergia/rjvm/blob/be9c54066c64a82879...
- andreabergia 3y agoI wanted to express the fact that everything that gets allocated (call stack, frames, classes, and objects) is alive and valid until the "root" VM is, thus I used 'a more or less everywhere. I also struggled with a got a ton of errors from the borrow checker initially, and I fixed many of those with a lot of explicit lifetimes, but it's not impossible that in some places they are unnecessary.
- celeritascelery 3y ago> I wanted to express the fact that everything that gets allocated (call stack, frames, classes, and objects) is alive and valid until the "root" VM is, thus I used 'a more or less everywhere. That's not being expressed in the type system. The lifetime 'a is unbounded (meaning you can make it anything you want, including 'static) so anything that shares 'a can outlive the vm without rust complaining. it would be no different then if you removed 'a completely. If you wanted to ensure anything couldn't outlive the vm you could tie the lifetime to a reference to the vm, but then the vm can't hold those values (it would be a self-referential lifetime).
- skitter 3y agoFunnily enough I did the same in an early wip version of my toy JVM. Ended up using unsafe to use 'static references internally but only hand out wrappers that include a reference to the JVM. This also ensures that objects/classes/… from one JVM can't be used in another one.
- MuffinFlavored 3y agoCould you not pass around Mutex<T> performantly?
- skitter 3y agoI'm not sure what you mean? Mutability wasn't the issue, lifetimes was. It already implemented interior mutability according to Java's rules.