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-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.5 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=no 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 CCF0F1F4B4 for ; Wed, 7 Apr 2021 23:24:52 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 4E67B121127; Thu, 8 Apr 2021 08:23:49 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id E527B121125 for ; Thu, 8 Apr 2021 08:23:46 +0900 (JST) Received: by filterdrecv-p3las1-canary-9b76658bd-9gh9m with SMTP id filterdrecv-p3las1-canary-9b76658bd-9gh9m-19-606E3F3C-28 2021-04-07 23:24:44.886378754 +0000 UTC m=+1316137.835586061 Received: from herokuapp.com (unknown) by geopod-ismtpd-2-0 (SG) with ESMTP id 1T6BqprwRh2xNPXtth-1Pw for ; Wed, 07 Apr 2021 23:24:44.711 +0000 (UTC) Date: Wed, 07 Apr 2021 23:24:44 +0000 (UTC) From: sam.saffron@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79329 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17762 X-Redmine-Issue-Author: mame X-Redmine-Sender: sam.saffron 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?GD31AXMrLYtZC3ZmvheLkg5nAqKYtjT=2Fa5aksj98ZWMn+meAp94hTLy+oNhIeG?= =?us-ascii?Q?6xjDNwhwZgz9S0SCDGHQdwtoFQf=2F64hDanWZvmi?= =?us-ascii?Q?ang1bV+0shLTVlqBqK195qghPeS3IGmnq3c2a9J?= =?us-ascii?Q?IhqpujelQBD0CzNxBaJ2UGmNKtKB3XGVgL5WVa+?= =?us-ascii?Q?2uE7vX9xLFsFTj2L+iKCG8L+SrYXfxv3pkqQslQ?= =?us-ascii?Q?cZl=2FNRmrGdCplsr6s=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103283 Subject: [ruby-core:103283] [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 sam.saffron (Sam Saffron). I am with @Eregon here: > ObjectSpace.trace_object_allocations_start as a side effect of a "require" seems like a mighty dangerous weapon. It will get checked into production at some point. Also not a fan of: `require "objspace/start_tracing"` Cause then ... do we have to add: `require "objspace/stop_tracing"` Redefining `p` also feels extremely radical. Overall a much prefer a deliberate API here: `t = ObjectSpace.allocation_tracer` `t.start` `t.stop` `t.debug(x)` ---------------------------------------- Feature #17762: A simple way to trace object allocation https://bugs.ruby-lang.org/issues/17762#change-91367 * 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/