Eregon (Benoit Daloze) wrote: > `Class#new`, `dup`, `clone` and `Marshal` always use the internal alloc function, because they guarantee to call `initialize`, `initialize_dup` or `initialize_clone`. Users have control over `initial...jhawthorn (John Hawthorn)
Currently we maintain the subclasses list for two separate purposes (we essentially have to different relationships we're putting into the same list): 1. On a T_MODULE, we track the T_ICLASSes created to include it into other classes...jhawthorn (John Hawthorn)
I merged my proposed design, which should restore Ruby 3.4's performance https://github.com/ruby/ruby/pull/16363 (forgot to tag this issue in the commit message, sorry) I'm going to look into backporting this to Ruby 4.0. We usually d...jhawthorn (John Hawthorn)
Currently we maintain the subclasses list for two separate purposes (we essentially have to different relationships we're putting into the same list): 1. On a T_MODULE, we track the T_ICLASSes created to include it into other classes...jhawthorn (John Hawthorn)
This adds "free_immediately: false" to the heap dump for any T_DATA which doesn't specify RUBY_TYPED_FREE_IMMEDIATELY. These are the objects which end up as T_ZOMBIE and will have their dfree callback deferred to later when the program i...jhawthorn (John Hawthorn)
Using Psych, load was actually more restrictive than safe_load. Using Gem::YAMLSerializer they were identical. We might as well use the same path for both methods. https://github.com/ruby/rubygems/commit/d8d927f889jhawthorn (John Hawthorn)
This had been the only user of Gem::SafeYAML.load for a long time. We might as well be consistent with all other uses and use safe_load. https://github.com/ruby/rubygems/commit/1b698779f5jhawthorn (John Hawthorn)
jhawthorn (John Hawthorn)02:26 AM Ruby Feature #21963: A solution to completely avoid allocated-but-uninitialized objects