From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 4927D1F4B4 for ; Wed, 31 Mar 2021 01:59:49 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id EC13E120EA0; Wed, 31 Mar 2021 10:58:48 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id EF98C120E9E for ; Wed, 31 Mar 2021 10:58:46 +0900 (JST) Received: by filterdrecv-p3las1-699f5f7ff5-7rwqm with SMTP id filterdrecv-p3las1-699f5f7ff5-7rwqm-18-6063D78F-2C 2021-03-31 01:59:43.789442584 +0000 UTC m=+631594.834271436 Received: from herokuapp.com (unknown) by ismtpd0202p1mdw1.sendgrid.net (SG) with ESMTP id Cab8heJiQSKxmjku_5aRaw for ; Wed, 31 Mar 2021 01:59:43.624 +0000 (UTC) Date: Wed, 31 Mar 2021 01:59:43 +0000 (UTC) From: mame@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79158 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17762 X-Redmine-Issue-Author: mame X-Redmine-Sender: mame X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?EJh2gqwnyqXtd++xo=2FinyA1V0bXouTB4FkWnzNiKb49PTqzuC7fDxQ3k+h=2Fazh?= =?us-ascii?Q?eCvicbcDbdRiRRKFXEMjCFFAxKo+34m=2F=2FrLydmJ?= =?us-ascii?Q?Ht11TIMr8iIZhOD+YgUT538cFRRgY65IlYm30iU?= =?us-ascii?Q?r+pJVvoXLMwzL520CtUUis9Y7OipzBFpRnXobK8?= =?us-ascii?Q?wqz4bSKgHd+SjixIzyWgJLiI+sRBjB04EqgKuUc?= =?us-ascii?Q?oIL9Q=2Fb0ONrRe9AlM=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103121 Subject: [ruby-core:103121] [Ruby master Feature#17762] A simple way to trace object allocation X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #17762 has been updated by mame (Yusuke Endoh). Eregon (Benoit Daloze) wrote in #note-3: > `require "objspace/trace"` automatically starting tracing seems dangerous, there is a pretty big performance penalty to enable it. > So I think the message on stderr is needed, and maybe it should be more explicit like `require "objspace/start_tracing"`. `require "objspace/start_tracing"` sounds good to me. > byroot (Jean Boussier) wrote in #note-2: > > I'm not too sure about that one. I suppose it's fine, but I'm not always in a situation where `p` is usable. Would `Object#allocation_source` be acceptable? > > How about `ObjectSpace.allocation_source(obj)`? This is also nice-to-have. `p ObjectSpace.allocation_source(obj)` is much better than ``` p [ObjectSpace.allocation_sourcefile(obj), ObjectSpace.allocation_sourceline(obj)] ``` .. But IMO, `p ObjectSpace.allocation_source(obj)` is too long for quick debugging. I guess this is the reason why #10932 proposed `include ObjectSpace`, but it pollutes the namespace needlessly. > `Object#allocation_source` wouldn't work for BasicObject and it would pollute Object/Kernel which seems suboptimal to me. I think this is a trade-off between robustness and usability. If you want general-purpose and robust solution, you can use the current APIs. The goal of this proposal is "useful and good enough in many cases". ---------------------------------------- Feature #17762: A simple way to trace object allocation https://bugs.ruby-lang.org/issues/17762#change-91190 * 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 #=> # @ (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/