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=-2.6 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 E91C11F4B4 for ; Tue, 30 Mar 2021 20:11:48 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 36CC5120E28; Wed, 31 Mar 2021 05:10:48 +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 DFBB2120D99 for ; Wed, 31 Mar 2021 05:10:45 +0900 (JST) Received: by filterdrecv-p3iad2-7d7c446bd4-zz5hq with SMTP id filterdrecv-p3iad2-7d7c446bd4-zz5hq-19-606385FE-36 2021-03-30 20:11:42.436219914 +0000 UTC m=+610720.478719177 Received: from herokuapp.com (unknown) by geopod-ismtpd-1-0 (SG) with ESMTP id LbWCJANkSPSwk4YvUbD27g for ; Tue, 30 Mar 2021 20:11:42.418 +0000 (UTC) Date: Tue, 30 Mar 2021 20:11:42 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79147 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17762 X-Redmine-Issue-Author: mame X-Redmine-Sender: Eregon 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr0jJqB1QRI96hUSB0qP3c?= =?us-ascii?Q?F13oUw+I78fmPoSh0UplpnqVt8fyb4x1+ukGCoN?= =?us-ascii?Q?ACOdP4dxL2MiVCVkYZUi6=2FQs4XKTbj8T9TaGq7u?= =?us-ascii?Q?6dcSlrOqhlbq6z2crxJbMJ9UuklL8xIg9VKkH0B?= =?us-ascii?Q?eyEBlDEfIKOurqJldvTgIjqavbt8CFJTswrXrQE?= =?us-ascii?Q?nUXmWV+n=2F4ynQym0U=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103112 Subject: [ruby-core:103112] [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 Eregon (Benoit Daloze). 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? ---------------------------------------- Feature #17762: A simple way to trace object allocation https://bugs.ruby-lang.org/issues/17762#change-91178 * 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 `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/