[ruby-core:120132] [Ruby master Misc#16124] Let the transient heap belong to objspace
From:
"ko1 (Koichi Sasada) via ruby-core" <ruby-core@...>
Date:
2024-12-08 06:55:33 UTC
List:
ruby-core #120132
Issue #16124 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Rejected transient heap was removed. ---------------------------------------- Misc #16124: Let the transient heap belong to objspace https://bugs.ruby-lang.org/issues/16124#change-110882 * Author: methodmissing (Lourens Naud=E9) * Status: Rejected * Assignee: ko1 (Koichi Sasada) ---------------------------------------- As per comment from Nobu in https://github.com/ruby/ruby/pull/2303#issuecom= ment-523248875 , I took an initial stab @ a tighter integration between obj= space and the transient heap in https://github.com/ruby/ruby/pull/2400 ### Benefits * 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 f= unction 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 i= nto all other reference sites where this source file (`transient_heap.c`) a= s previously just used for API * I'm not sure exactly of the boundary Koichi had in mind for the GC compil= e module and how tightly it should (or shouldn't) be coupled to the transie= nt heap. `struct rb_objspace*` declarations elsewhere for example reveals n= othing 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 no= t an experimental feature anymore and has been stable for quite some time w= ith plausible performance benefits. The downside of that is `gc.c` is quite= dense already, but then all ruby heap management concerns belong to one co= mpile unit. In a similar vein the global method cache could perhaps belong to the VM in= stance as well, effectively better alignment with MVM and also easier to ha= ve a balanced VM setup and teardown sequence without anything left dangling= on ruby shutdown. Thoughts? --=20 https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.rub= y-lang.org/