Project

General

Profile

Actions

Feature #17103

closed

Add a :since option to ObjectSpace.dump_all

Added by byroot (Jean Boussier) over 4 years ago. Updated almost 4 years ago.

Status:
Closed
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.

Actions #1

Updated by sawa (Tsuyoshi Sawada) over 4 years ago

  • Description updated (diff)

Updated by ko1 (Koichi Sasada) about 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years ago

That's a good point. I added:

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

Updated by matz (Yukihiro Matsumoto) about 4 years ago

OK. Accepted.

Matz.

Updated by byroot (Jean Boussier) almost 4 years ago

This was merged in Ruby 3.0 and can now be closed.

Actions #10

Updated by jeremyevans0 (Jeremy Evans) almost 4 years ago

  • Status changed from Open to Closed
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0