From: jean.boussier@... Date: 2020-07-23T08:52:12+00:00 Subject: [ruby-core:99297] [Ruby master Bug#17045] ObjectSpace.dump_all should allocate as little as possible in the GC heap Issue #17045 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #17045: ObjectSpace.dump_all should allocate as little as possible in the GC heap https://bugs.ruby-lang.org/issues/17045 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- For context I'm working on a [heap profiler](https://github.com/Shopify/heap-profiler). In short the use case is like this (pseudo code): ```ruby GC.disable ObjectSpace.dump_all(output: file1) # run the user code ObjectSpace.dump_all(output: file2) compute_the_diff_and_report_statistics(file1, file2) ``` Ideally I would need `ObjectSpace.dump_all` to not modify the GC heap at all so that an empty user code would report an empty diff. However as showcased [in this test case](https://github.com/Shopify/ruby/commit/c9c0f46318e8018e269840f3d173d62eeebb1176), `dump_all(output: <#File:/path.json>)` currently allocates 4 objects: - The `File` instance passed as `output:` is re-opened by `rb_io_stdio_file` in `dump_output` and I don't quite understand why. - The `scan_args` in `dump_all` allocates a `Hash` instance. Would using the new `Primitive` interface avoid that? - Another hash is allocated but I'm unsure where it comes from. - An `IMEMO "imemo_type"=>"callcache"` is allocated. Surprisingly it can be avoided by calling `ObjectSpace.dump_all(**opts)` Could any of these be eliminated? -- https://bugs.ruby-lang.org/ Unsubscribe: