3 ms·

You're right there – It looks like the author is trying to express "this lifetime lasts as long as the VM exists", which isn't possible to express in Rust. For

You're right there – It looks like the author is trying to express "this lifetime lasts as long as the VM exists", which isn't possible to express in Rust. For VM::new, the callsite just picks a lifetime that lasts long enough – even if that outlasts the VM, making the lifetime useless. This is a bug and unsound.

bialpio 3y ago
My understanding is that if Rust let you compile it, then there is no bug with a lifetime (the code doesn't use `unsafe`). There may be something magical happening under the hood that I do not fully understand, but in Rust I trust. ;)
- skitter 3y ago
  Your understanding of Rust is correct, but the code uses unsafe: https://github.com/andreabergia/rjvm/blob/93e7e48db085e780b0787aaf37bb3c77d6cfa7b8/vm/src/gc.rs#L39 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.
  - bialpio 3y ago
    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/93e7e48db085e780b0787aaf37bb3c77d6cfa7b8/vm/tests/integration/real_code_tests.rs#L10 https://github.com/andreabergia/rjvm/blob/93e7e48db085e780b0...
    - skitter 3y ago
      VM creation is using unsafe (the line I pointed out above). You're right, I can't find any deallocation either – but weirdly it /does/ segfault (or sometimes have other memory related errors) if I drop the VM while it's heap is still referenced. 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.
      - andreabergia 3y ago
        That sounds reasonable (and way better than what I have implemented). 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. :)

bialpio 3y ago

My understanding is that if Rust let you compile it, then there is no bug with a lifetime (the code doesn't use `unsafe`). There may be something magical happening under the hood that I do not fully understand, but in Rust I trust. ;)

skitter 3y ago
Your understanding of Rust is correct, but the code uses unsafe: https://github.com/andreabergia/rjvm/blob/93e7e48db085e780b0787aaf37bb3c77d6cfa7b8/vm/src/gc.rs#L39 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.
- bialpio 3y ago
  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/93e7e48db085e780b0787aaf37bb3c77d6cfa7b8/vm/tests/integration/real_code_tests.rs#L10 https://github.com/andreabergia/rjvm/blob/93e7e48db085e780b0...
  - skitter 3y ago
    VM creation is using unsafe (the line I pointed out above). You're right, I can't find any deallocation either – but weirdly it /does/ segfault (or sometimes have other memory related errors) if I drop the VM while it's heap is still referenced. 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.
    - andreabergia 3y ago
      That sounds reasonable (and way better than what I have implemented). 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. :)