Issue #16124 has been updated by nobu (Nobuyoshi Nakada).


I'm positive about this, except for the performance.
Do you have any numbers?

----------------------------------------
Misc #16124: Let the transient heap belong to objspace
https://bugs.ruby-lang.org/issues/16124#change-81595

* Author: methodmissing (Lourens Naud=E9)
* Status: Assigned
* Priority: Normal
* 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?



-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>