[ruby-core:103103] [Ruby master Feature#17762] A simple way to trace object allocation
From:
shevegen@...
Date:
2021-03-30 15:45:12 UTC
List:
ruby-core #103103
Issue #17762 has been updated by shevegen (Robert A. Heiler).
I think this is a good suggestion.
Please correct me if my assumptions are wrong, but if I understood the general gist of it correctly
then the main point here is that, rather than focusing on specific names, such as
ObjectSpace.trace_object_allocations_start or ObjectSpace.this_aptly_named_method_is_really_not_easy_to_remember,
the main idea is that you can, sort of "activate" a more general debug-centric way to handle
output that may be relevant for getting additional information about different
objects. In the specific example, you tie it to Kernel#p such as the:
p obj
example shows. So basically, the idea is to get more information that is useful for
debugging, without depending on specific API names as such, yes?
In that case I think it's a good idea.
To your three questions, I'll only comment on the Kernel#p last part.
I think it is fine to modify Kernel#p in this case. You could perhaps add
ObjectSpace.enable_tracing, ObjectSpace.strop_tracing or just a flipper
ObjectSpace.flip or ObjectSpace.trace for simpler names. Good API design
is hard. What I like about the idea is that you can sort of get more
information with simple things such as p (or perhaps pp ... could pp
also be used here? tenderlove once wrote that he is a puts debugger,
on his blog; I am a pp debugger! pp all the things).
----------------------------------------
Feature #17762: A simple way to trace object allocation
https://bugs.ruby-lang.org/issues/17762#change-91169
* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
----------------------------------------
How about having a short hand to `ObjectSpace.trace_object_allocations_start`, `ObjectSpace.allocation_sourcefile` and `ObjectSpace.allocation_sourceline`?
They are a very powerful tool for debugging and code-reading which allows us to identify an allocation site of an object.
Though they are never lightweight, they are the last resort when you try debugging code written by someone else.
However, the names are too long for me to remember and to type. Whenever I want to use them, I have to google, copy and paste the names.
## Proposal
To enable trace allocations:
```
require "objspace/trace" #=> objspace/trace is enabled
```
To show the allocation site of an object:
```
p obj #=> #<Object:0x...> @ (file.rb):(lineno)
```
## Example
```
require "objspace/trace"
require "active_support/all"
p ActiveSupport::VERSION::STRING
#=> "6.1.3.1" @ /home/mame/work/ruby/local/lib/ruby/gems/3.1.0/gems/activesupport-6.1.3.1/lib/active_support/gem_version.rb:15
```
## Discussion
I've attached a simple patch that is originally authored by @ko1 .
* Is the message `objspace/trace is enabled` needed or not?
* To stop the trace, you need to use `Object.trace_object_allocations_stop`. But, I guess that it is rare that we need to stop it during debugging.
* Is it too radical to redefine `Kernel#p`? I think that it is good enough for many cases. When it matters, the original APIs (`ObjectSpace.trace_object_allocations_start`, ...) can be used.
---Files--------------------------------
objspace-trace.patch (631 Bytes)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>