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.7 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_HI,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 66F701F4B4 for ; Wed, 31 Mar 2021 07:05:56 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 0C249120EFC; Wed, 31 Mar 2021 16:04:53 +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 0463B120EFB for ; Wed, 31 Mar 2021 16:04:50 +0900 (JST) Received: by filterdrecv-p3las1-699f5f7ff5-z8fck with SMTP id filterdrecv-p3las1-699f5f7ff5-z8fck-19-60641F45-C6 2021-03-31 07:05:41.901428461 +0000 UTC m=+649955.596026893 Received: from herokuapp.com (unknown) by geopod-ismtpd-4-2 (SG) with ESMTP id -H14EttCSFeR9pMTCL2qjg for ; Wed, 31 Mar 2021 07:05:41.702 +0000 (UTC) Date: Wed, 31 Mar 2021 07:05:41 +0000 (UTC) From: jean.boussier@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79167 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17762 X-Redmine-Issue-Author: mame X-Redmine-Sender: byroot 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?AchqQMoUBMcQgz7gop0XiYUiatGIY7E61JGsTL4FvjeCm0aOQj1iWOzT97lKwi?= =?us-ascii?Q?ArV6e78EdSdP5BcrAZlDc8IXbtv4rKnS1hg7spa?= =?us-ascii?Q?QrL4=2FvWdbktUJyImkl6f2admyGH4UiPmi=2FufEv5?= =?us-ascii?Q?eBrJvy6VYqgt=2Fv46YETZF9Xn75g+BHvVWamy+Rx?= =?us-ascii?Q?lRg2ChzMqdMiK6nXN4InsDAioe1r9Sp4mz4D8mZ?= =?us-ascii?Q?wmC0xqPk3aFcHvfFI=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103124 Subject: [ruby-core:103124] [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 byroot (Jean Boussier). > How about ObjectSpace.allocation_source(obj)? That would be fine by me, it is a much more reasonable than the `[ObjectSpace.allocation_sourcefile(obj), ObjectSpace.allocation_sourceline(obj)]` I write almost daily. Even though a the name is very slightly weird when put in context with `Method#source_location`, as `source` have a different meaning in both of these. But `allocation_location` would be even weirder I think. > require "objspace/start_tracing" sounds good to me. While we're at it could we also alias the `::trace_object_allocations_*` family of methods ? ```ruby ObjectSpace.trace_object_allocations_start => ObjectSpace.start_tracing ObjectSpace.trace_object_allocations_stop => ObjectSpace.stop_tracing ObjectSpace.trace_object_allocations => ObjectSpace.trace ObjectSpace.trace_object_allocations_clear => ObjectSpace.clear_traces ``` Or, I know you'd like to keep this change limited, but maybe have a simpler interface? ```ruby ObjectSpace.trace {} ObjectSpace.tracing_enabled # => true/false ObjectSpace.tracing_enabled=(true/false) ObjectSpace.clear_traces ``` ---------------------------------------- Feature #17762: A simple way to trace object allocation https://bugs.ruby-lang.org/issues/17762#change-91199 * 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/