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=-3.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS 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 6DA7A1F4BD for ; Mon, 7 Oct 2019 22:52:58 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 4E2ED120A20; Tue, 8 Oct 2019 07:52: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 61196120913 for ; Tue, 8 Oct 2019 07:52:47 +0900 (JST) Received: by filter0107p3las1.sendgrid.net with SMTP id filter0107p3las1-12220-5D9BC1C0-13 2019-10-07 22:52:48.190231907 +0000 UTC m=+22053.496187614 Received: from herokuapp.com (unknown [54.158.92.1]) by ismtpd0053p1mdw1.sendgrid.net (SG) with ESMTP id -P7dOYGzRMy0BccEDblJ5Q for ; Mon, 07 Oct 2019 22:52:47.679 +0000 (UTC) Date: Mon, 07 Oct 2019 22:52:48 +0000 (UTC) From: lourens@bearmetal.eu Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70859 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16245 X-Redmine-Issue-Author: sam.saffron X-Redmine-Sender: methodmissing 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?Fr=2F4MkNsnJ5O85XS4movydqTd1a9M98=2FgJAFvUl026NNOe5twlbbrl2fblfgUF?= =?us-ascii?Q?ozMwL2upte9C0V680t4PsuAhQXPdU01dLYllO5W?= =?us-ascii?Q?OzWQYOcgdvkUWWNfoIi7pqM7RZf3WnwhfVzkpfX?= =?us-ascii?Q?Jj8JehU=2FxgvPQnRNlSprKUcj=2F1Tds8kjVj4tBTs?= =?us-ascii?Q?OBWibfr6FK2Y7O=2Fm0cFapLhOwNAVKdKYYwQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95272 Subject: [ruby-core:95272] [Ruby master Feature#16245] Add interfaces to count and measure size all IMEMO objects 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16245 has been updated by methodmissing (Lourens Naud=E9). sam.saffron (Sam Saffron) wrote: > Koichi introduced an experimental gem: https://github.com/ko1/iseq_collec= tor > = > It allows: > = > ObjectSpace.each_iseq{|iseq| ...} > ObjectSpace.count_iseq #=3D> Integer > ObjectSpace.memsize_of_all_iseq (should not generate RubyVM::InstructionS= equence wrappers for IMEMOs) > = > Since the wrapper object RubyVM::InstructionSequence is lazily allocated= , ObjectSpace.each_object does not find these IMEMOs unless they have been = wrapped. This design is good and conserves memory. = > = > `count_iseq` and `memsize_of_all_iseq` are very powerful metrics most lar= ge Ruby deployments can use to automatically detect method leaks introduced= via meta programming. These issues are invisible now short of walking a he= ap dump. = > = > Can we add the new interface into 2.7? I worked on `imemo_memsize` some time ago to correctly reflect the type siz= es in https://github.com/ruby/ruby/commit/90c4bd2d2bd10b19c2b09834396553742= bc7e8a4 which makes heap dumps more accurate. I understand the API proposal= , but also I believe the intention was for these objects to be internal and= not necessarily to be exposed through API. However I do suspect for large = Rails applications their combined footprint can add up, especially for the = types that can allocate heap memory too: * imemo_ment (method entries) * imemo_iseq (as per your description above) * imemo_env (bindings) * imemo_tmpbuf (tried to support these on the transient heap but found them= to be almost never used much in practice as it appears to be a fallback fo= r `ALLOCA` under some circumstances. * imemo_ast I have not had any free time to investigate further, but I think this is an= interesting storage class to explore further and I'd be interesting in hel= ping, whichever way the proposal goes. ---------------------------------------- Feature #16245: Add interfaces to count and measure size all IMEMO objects https://bugs.ruby-lang.org/issues/16245#change-81948 * Author: sam.saffron (Sam Saffron) * Status: Open * Priority: Normal * Assignee: = * Target version: = ---------------------------------------- Koichi introduced an experimental gem: https://github.com/ko1/iseq_collector It allows: ObjectSpace.each_iseq{|iseq| ...} ObjectSpace.count_iseq #=3D> Integer ObjectSpace.memsize_of_all_iseq (should not generate RubyVM::InstructionSeq= uence wrappers for IMEMOs) Since the wrapper object RubyVM::InstructionSequence is lazily allocated, = ObjectSpace.each_object does not find these IMEMOs unless they have been wr= apped. This design is good and conserves memory. = `count_iseq` and `memsize_of_all_iseq` are very powerful metrics most large= Ruby deployments can use to automatically detect method leaks introduced v= ia meta programming. These issues are invisible now short of walking a heap= dump. = Can we add the new interface into 2.7? -- = https://bugs.ruby-lang.org/ Unsubscribe: