Project

General

Profile

Feature #17103

Add a :since option to ObjectSpace.dump_all

Added by byroot (Jean Boussier) about 2 months ago. Updated 30 days ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:99474]

Description

Patch: https://github.com/ruby/ruby/pull/3368

This is useful for seeing what a block of code allocated, e.g.

GC.start
GC.disable
gc_gen = GC.count
ObjectSpace.trace_object_allocations do
  # run some code
end
allocations = ObjectSpace.dump_all(output: :file, since: gc_gen)
GC.enable
GC.start
retentions = ObjectSpace.dump_all(output: :file, since: gc_gen)

For context, this is what I do in https://github.com/Shopify/heap-profiler, except that I have to dump the entire heap three times and then do a diff. This new API would allow me to dump the entire heap only once and then do two much-faster single-generation dumps without doing the diff.

#1

Updated by sawa (Tsuyoshi Sawada) about 2 months ago

  • Description updated (diff)

Updated by ko1 (Koichi Sasada) about 2 months ago

sorry I can't understand the specification.

also https://github.com/ruby/ruby/pull/3368/files doesn't have a doc.
could you explain more?

Updated by byroot (Jean Boussier) about 2 months ago

ko1 (Koichi Sasada) this parameter allow to do partial heap dumps. e.g. dump_all(since: 42), means to only dump objects of the 42th generation and later. Basically like adding a if ObjectSpace.allocation_generation(obj) >= 42.

This would be very useful to me, because a minimal heap dump of our application is over 1GiB and take almost a minute to be performed. Often times I'm only interested by allocations past a certain point, such filtering criterias would allow for much smaller and faster dumps, with less "noise" in them.

Please let me know if that is still unclear.

also https://github.com/ruby/ruby/pull/3368/files doesn't have a doc.

That's an oversight on my part, I'll update the PR to add a documentation for that new parameter as soon as possible.

Updated by ko1 (Koichi Sasada) about 1 month ago

this feature strongly connected with trace_object_allocations, right? so please write it on document.
what happens on without trace_object_allocations? it is unclear.

Updated by byroot (Jean Boussier) about 1 month ago

this feature strongly connected with trace_object_allocations, right?

Indeed.

so please write it on document. what happens on without trace_object_allocations? it is unclear.

I changed:

Objects that were allocated with object allocation tracing disabled are not dumped.

to:

Objects that were allocated without object allocation tracing enabled
are ignored. See ::trace_object_allocations for more information and
examples.

Is that acceptable?

Updated by ko1 (Koichi Sasada) about 1 month ago

I missed "allocation tracing disabled are not dumped" sentence. And changed version is more helpful.

Now I don't have any objection.
One suggestion is, "since" integer is not clear yet (even if trace_object_allocations describes it), so it is helpful to explain it is integer from GC.count.

Updated by byroot (Jean Boussier) about 1 month ago

That's a good point. I added:

The current generation can be accessed using GC::count.

Updated by matz (Yukihiro Matsumoto) 30 days ago

OK. Accepted.

Matz.

Also available in: Atom PDF