Skip to content

Prevent ObjectSpace.count_objects from allocating extra arrays #13906

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 16, 2025

Conversation

mame
Copy link
Member

@mame mame commented Jul 16, 2025

ObjectSpace.count_objects could cause an unintended array allocation. It returns a hash like { :T_ARRAY => 100, :T_STRING => 100, ... }, so it creates the key symbol (e.g., :T_STRING) for the first time. On rare occations, this symbol creation internally allocates a new array for symbol management.

This led to a problematic side effect where calling count_objects twice in a row could produce inconsistent results: the first call would trigger the hidden array allocation, and the second call would then report an increased count for :T_ARRAY.

This behavior caused test failures in test/ruby/test_allocation.rb, which performs a baseline measurement before an operation and then asserts the exact number of new allocations.

https://rubyci.s3.amazonaws.com/openbsd-current/ruby-master/log/20250716T053005Z.fail.html.gz

  1. Failure:
    TestAllocation::ProcCall::WithBlock#test_ruby2_keywords [...]:
    Expected 1 array allocations for "r2k.(1, a: 2, &block)", but 2 arrays allocated.

This change resolves the issue by pre-interning all key symbols used by ObjectSpace.count_objects before its counting. This eliminates the side effect and ensures the stability of allocation-sensitive tests.

`ObjectSpace.count_objects` could cause an unintended array allocation.
It returns a hash like `{ :T_ARRAY => 100, :T_STRING => 100, ... }`, so
it creates the key symbol (e.g., `:T_STRING`) for the first time. On
rare occations, this symbol creation internally allocates a new array
for symbol management.

This led to a problematic side effect where calling `count_objects`
twice in a row could produce inconsistent results: the first call would
trigger the hidden array allocation, and the second call would then
report an increased count for `:T_ARRAY`.

This behavior caused test failures in `test/ruby/test_allocation.rb`,
which performs a baseline measurement before an operation and then
asserts the exact number of new allocations.

https://rubyci.s3.amazonaws.com/openbsd-current/ruby-master/log/20250716T053005Z.fail.html.gz

>   1) Failure:
> TestAllocation::ProcCall::WithBlock#test_ruby2_keywords [...]:
> Expected 1 array allocations for "r2k.(1, a: 2, &block)", but 2 arrays allocated.

This change resolves the issue by pre-interning all key symbols used by
`ObjectSpace.count_objects` before its counting. This eliminates the
side effect and ensures the stability of allocation-sensitive tests.

Co-authored-by: Koichi Sasada <ko1@atdot.net>
@mame mame force-pushed the preallocate-T_XXX-symbols-for-count_objects branch from b4d59b9 to 0229f80 Compare July 16, 2025 08:32
@mame mame enabled auto-merge (rebase) July 16, 2025 08:33
@mame mame merged commit 6d17a3e into master Jul 16, 2025
148 checks passed
@mame mame deleted the preallocate-T_XXX-symbols-for-count_objects branch July 16, 2025 09:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy