ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: mame@ruby-lang.org
To: ruby-core@ruby-lang.org
Subject: [ruby-core:103840] [Ruby master Feature#17762] A simple way to trace object allocation
Date: Fri, 14 May 2021 05:03:08 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-91960.20210514050308.18@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17762.20210330145723.18@ruby-lang.org

Issue #17762 has been updated by mame (Yusuke Endoh).

Assignee set to mame (Yusuke Endoh)
Status changed from Closed to Assigned

I realized that the compatibility of this library is not important at all, because this is a tool for human's debugging. Any codebase must not use it. This means that we can change the file name and APIs anytime if needed, even after it is release.

So, tentatively, I've committed my proposal as `require "objspace/trace"`. I've heard @ko1 plans to create `lib/debug/run.rb` to enable a new debugger feature that he is now developing. `require "debug/run"` sounds simple and great to me, so I think `require "objspace/trace"` is also good enough. However, I'm okay to change if many people prefer `require "objspace/start_tracing"`.

I admit redefining `Kernel#p` may be radical. But I want to see if it brings any actual issue. I'm not against adding `allocation_location` or something. If anyone wants it too, a pull request is welcome.

Just an idea: it might be good to create a rubocop rule to prevent `require "objspace/trace"` from being committed accidentally.

----------------------------------------
Feature #17762: A simple way to trace object allocation
https://bugs.ruby-lang.org/issues/17762#change-91960

* Author: mame (Yusuke Endoh)
* Status: Assigned
* Priority: Normal
* Assignee: mame (Yusuke Endoh)
----------------------------------------
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 `ObjectSpace.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/

      parent reply	other threads:[~2021-05-14  5:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 14:57 [ruby-core:103102] [Ruby master Feature#17762] A simple way to trace object allocation mame
2021-03-30 15:45 ` [ruby-core:103103] " shevegen
2021-03-30 15:59 ` [ruby-core:103104] " jean.boussier
2021-03-30 19:16 ` [ruby-core:103108] " eregontp
2021-03-30 19:43 ` [ruby-core:103110] " tenderlove
2021-03-30 20:11 ` [ruby-core:103112] " eregontp
2021-03-31  1:52 ` [ruby-core:103120] " mame
2021-03-31  1:59 ` [ruby-core:103121] " mame
2021-03-31  2:02 ` [ruby-core:103122] " mame
2021-03-31  2:04 ` [ruby-core:103123] " mame
2021-03-31  7:05 ` [ruby-core:103124] " jean.boussier
2021-03-31 18:42 ` [ruby-core:103131] " eregontp
2021-04-01  9:58 ` [ruby-core:103148] " jean.boussier
2021-04-07 23:24 ` [ruby-core:103283] " sam.saffron
2021-04-08  8:15 ` [ruby-core:103296] " jean.boussier
2021-04-09 18:18 ` [ruby-core:103351] " eregontp
2021-04-16  8:05 ` [ruby-core:103477] " matz
2021-05-14  5:03 ` mame [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-91960.20210514050308.18@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).