Let the transient heap belong to objspace
As per comment from Nobu in https://github.com/ruby/ruby/pull/2303#issuecomment-523248875 , I took an initial stab @ a tighter integration between objspace and the transient heap in https://github.com/ruby/ruby/pull/2400
- 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_heapbecomes 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
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.cis 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.