From: "Eregon (Benoit Daloze)" <noreply@...>
Date: 2021-12-14T11:10:16+00:00
Subject: [ruby-core:106651] [Ruby master Feature#18364] Add GC.stat_pool for Variable Width Allocation

Issue #18364 has been updated by Eregon (Benoit Daloze).


meeting log is https://github.com/ruby/dev-meeting-log/blob/master/DevelopersMeeting20211209Japan.md

@ko1 said:
> GC.stat returns a flat hash (Symbol to Numeric map) now. This proposal changes it so that the method returns a nested hash.

But that is *not* this proposal or the description of this ticket.
@ko1 were you confused by this ticket description maybe?
I think this is why the resolution is so far from what was discussed here: it seems the description of this issue wasn't read properly and understood.

To make it clear, breaking existing usages of GC.stat which assume it's Integer/Numeric values will bring compatibility issues, and they will only appear late when VWA is made default.
I.e., that would be a significant breaking change, and so it makes no sense to me.

peterzhu2118 (Peter Zhu) wrote in #note-12:
> I think we should change API for rb_gc_stat to return `VALUE` instead. There probably isn't many users of this API so it shouldn't be a breaking change for many.

That seems very risky, because `size_t` and `VALUE` are both integer types, so code using it wouldn't notice the change but would likely just the print the nested Hash address as an integer which is unwanted.
I think the only possibility here is to raise for that C API if the value is not an Integer.

> We can still achieve this by checking that the non-numeric values of the key are of the correct type and re-using it.
> Although, this would significantly increase the complexity of the code for `GC.stat`.

How so? By having the caller do something like `h = { size_heap: {} }; GC.stat`?
But the caller code shouldn't need to know about this key.
Or maybe you mean `h = GC.stat; GC.stat(h)`? I'm not sure it's a common pattern.

----------------------------------------
Feature #18364: Add GC.stat_pool for Variable Width Allocation
https://bugs.ruby-lang.org/issues/18364#change-95323

* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
# GitHub PR: https://github.com/ruby/ruby/pull/5177

We're proposing an API to get statistics for size pools for Variable Width Allocation similar to `GC.stat`. This will make it easier for us (and other developers) to tune VWA.

Before 3.1 release, we plan to keep this method hidden from the documentation using `:nodoc:` since it is not useful when not using VWA.

For example:

```ruby
# Get stats for size pool 2
puts GC.stat_pool(2)
#=> {:slot_size=>160, :heap_allocatable_pages=>80, :heap_eden_pages=>14, :heap_eden_slots=>1424, :heap_tomb_pages=>0, :heap_tomb_slots=>0}
puts GC.stat_pool(2, :heap_eden_pages)
#=> 14
```

We aim to keep the keys in the outputted hash the same as the keys used in `GC.stat`.

We chose to implement a new method instead of re-using an existing API (`GC.stat`) because the keys returned by `GC.stat_pool` will not be the same as `GC.stat`. We believe that having `GC.stat` return different shapes of hashes based on its arguments is confusing.




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

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