Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'Called is_live() on 0, which maps to an empty space' in weak ref processing #176

Open
qinsoon opened this issue Sep 20, 2024 · 2 comments
Labels
bug Something isn't working workaround

Comments

@qinsoon
Copy link
Member

qinsoon commented Sep 20, 2024

Saw the following error in #175.

thread 'MMTk Worker' panicked at 'Called is_live() on 0, which maps to an empty space', /home/runner/.cargo/git/checkouts/mmtk-core-3306bdeb8eb4322b/73be50d/src/policy/sft.rs:127:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/eb26296b556cef10fb713a38f3d16b9886080f26/library/core/src/panicking.rs:67:14
   2: <mmtk::policy::sft::EmptySpaceSFT as mmtk::policy::sft::SFT>::is_live
   3: clear_weak_refs
             at /home/runner/work/mmtk-julia/mmtk-julia/vm/julia/src/mmtk-gc.c:145:22
   4: <mmtk_julia::scanning::ScanFinalizersSingleThreaded<C> as mmtk::scheduler::work::GCWork<mmtk_julia::JuliaVM>>::do_work
   5: mmtk::scheduler::worker::GCWorker<VM>::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
@qinsoon
Copy link
Member Author

qinsoon commented Sep 30, 2024

There are two issues here:

  1. Julia weak refs are stored in a thread-local array list. The weak refs may get copied, and the array list is not updated and they still include the old references.
  2. The values that weak refs refer to may get removed. We are not dealing with object forwarding in our weak ref processing. See clear_weak_refs in mmtk-gc.c.

The simple solution is to pin both: the weak ref, and the value they refer to. See mmtk/julia@51ba2a6.

@k-sareen
Copy link
Contributor

There are many such instances in ART and the solution they have/I have co-opted is to visit these locations at the end of the transitive closure but before the "release" and fixup all pointers since we have complete information at that time. I use the mmtk_get_forwarded_object API to get the new address. The problem in Julia, of course, might be that it's unclear which locations are actually storing pointers.

@qinsoon qinsoon added the bug Something isn't working label Sep 30, 2024
qinsoon added a commit to mmtk/julia that referenced this issue Oct 11, 2024
This PR adds a few more pining for types in the native heap, and exposes globally rooted symbols so we can trace them in the MMTk binding. With this PR, we can run moving Immix without transitively pinning `global_roots_table`. See mmtk/mmtk-julia#170.
* Add `jl_gc_pin`
* Use `jl_gc_pin` to pin `BigFloat` for MPFR
* Rename `PTR_PIN` to `OBJ_PIN`. Additionally add `PTR_PIN` which handles cases for internal pointers.
* Pin objects that are used as key in `jl_codectx_t.global_targets`
* Pin objects that are stored in `jl_codectx_t.PhiNodes`
* Pin objects that are referred to by `jl_cgval_t`
* Disable GC before doing perm alloc in `jl_get_layout` (see mmtk/mmtk-julia#172)
* Pin weak references and the referee (see mmtk/mmtk-julia#176)
* Pin objects that are used in `libuv`'s handle.
* Pin `jl_task_t.completion_future` (see mmtk/mmtk-julia#179)
* Pin all `jl_codeinst_t` objects.
* Pin all `jl_method_instance_t` objects.
* Pin all `jl_module_t` objects.
* Pin all `jl_task_t` objects.
* Expose some `JL_GLOBALLY_ROOTED` symbols, such as `newly_inferred`, `task_done_hook_func`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working workaround
Projects
None yet
Development

No branches or pull requests

2 participants