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 726FF1F4B4 for ; Wed, 31 Mar 2021 02:04:19 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C4128120EAA; Wed, 31 Mar 2021 11:03:19 +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 2017B120EA8 for ; Wed, 31 Mar 2021 11:03:17 +0900 (JST) Received: by filterdrecv-p3las1-699f5f7ff5-7rwqm with SMTP id filterdrecv-p3las1-699f5f7ff5-7rwqm-18-6063D89F-20 2021-03-31 02:04:15.248668106 +0000 UTC m=+631866.293496937 Received: from herokuapp.com (unknown) by ismtpd0128p1iad2.sendgrid.net (SG) with ESMTP id dPerD7WeSr-t2fES68e6FQ for ; Wed, 31 Mar 2021 02:04:15.085 +0000 (UTC) Date: Wed, 31 Mar 2021 02:04:15 +0000 (UTC) From: mame@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79160 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=2FinyA1V0bXouTB4FkWnzNiKb494JGwjuKdpJMxLErWf=2F3?= =?us-ascii?Q?y2feSZx7vrOdJhQFVBvFKBQzUzIf82sUQQqQJUL?= =?us-ascii?Q?vxsAegApmfszbtUk20fiXu0eHytOfhm7Pn82D=2Fr?= =?us-ascii?Q?JyztAxtuD8xsXQvdty7lOExQHfmDTia4e4k9CH2?= =?us-ascii?Q?7SjEm0bHIZKjYjBWep4ImwCjSZ2JALdJbynQOlH?= =?us-ascii?Q?Y+pnejhIjG41hnjSE=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103123 Subject: [ruby-core:103123] [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-5: > tenderlovemaking (Aaron Patterson) wrote in #note-4: > > I don't think it's needed. If you require the file, you know it's enabled. > > For the person who just wrote it it's clear enough. > But what if that accidentally gets committed and the app/program is N times slower and it's hard to find out why? Agreed. I'm worried I may commit it inadvertently after debugging is finished. But I'm unsure if the message is helpful to prevent the accident. A real-world application tends to print a lot of log messages, so the warning may be overlooked easily. ---------------------------------------- Feature #17762: A simple way to trace object allocation https://bugs.ruby-lang.org/issues/17762#change-91192 * 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/