Misc #16124

Let the transient heap belong to objspace

Added by methodmissing (Lourens Naudé) over 1 year ago. Updated over 1 year ago.



As per comment from Nobu in , I took an initial stab @ a tighter integration between objspace and the transient heap in


  • Multi-VM (MVM) friendly - ( vm -> objspace -> theap )
  • The 32MB (current size) arena lazy allocated on ruby init is now properly freed on shutdown as well
  • It feels strange that the evacuation from the current global theap is to objspace, whereas the space evacuated from is a global arena.

Not so great

  • A fast reference to a global variable global_transient_heap becomes a function call to rb_objspace_get_theap() and related pointer chasing from vm -> objspace -> theap
  • Some internal transient heap structs moved to the header file now leaks into all other reference sites where this source file (transient_heap.c) as previously just used for API
  • I'm not sure exactly of the boundary Koichi had in mind for the GC compile module and how tightly it should (or shouldn't) be coupled to the transient heap. struct rb_objspace* declarations elsewhere for example reveals nothing about the structure members for example, whereas with this PR a lot of transient heap internals are exposed via the header file now
  • Also possible to move transient_heap.c into gc.c - I feel theap is not an experimental feature anymore and has been stable for quite some time with plausible performance benefits. The downside of that is gc.c is quite dense already, but then all ruby heap management concerns belong to one compile unit.

In a similar vein the global method cache could perhaps belong to the VM instance as well, effectively better alignment with MVM and also easier to have a balanced VM setup and teardown sequence without anything left dangling on ruby shutdown.


Also available in: Atom PDF