From: lourens@bearmetal.eu
To: ruby-core@ruby-lang.org
Subject: [ruby-core:95272] [Ruby master Feature#16245] Add interfaces to count and measure size all IMEMO objects
Date: Mon, 07 Oct 2019 22:52:48 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-81948.20191007225247.dca875cb93e6b494@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16245.20191007220247@ruby-lang.org
Issue #16245 has been updated by methodmissing (Lourens Naudé).
sam.saffron (Sam Saffron) wrote:
> Koichi introduced an experimental gem: https://github.com/ko1/iseq_collector
>
> It allows:
>
> ObjectSpace.each_iseq{|iseq| ...}
> ObjectSpace.count_iseq #=> Integer
> ObjectSpace.memsize_of_all_iseq (should not generate RubyVM::InstructionSequence 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 large Ruby deployments can use to automatically detect method leaks introduced via meta programming. These issues are invisible now short of walking a heap dump.
>
> Can we add the new interface into 2.7?
I worked on `imemo_memsize` some time ago to correctly reflect the type sizes in https://github.com/ruby/ruby/commit/90c4bd2d2bd10b19c2b09834396553742bc7e8a4 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 for `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 helping, 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 #=> Integer
ObjectSpace.memsize_of_all_iseq (should not generate RubyVM::InstructionSequence 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 large Ruby deployments can use to automatically detect method leaks introduced via 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: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
next prev parent reply other threads:[~2019-10-07 22:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-16245.20191007220247@ruby-lang.org>
2019-10-07 22:02 ` [ruby-core:95267] [Ruby master Feature#16245] Add interfaces to count and measure size all IMEMO objects sam.saffron
2019-10-07 22:07 ` [ruby-core:95268] " sam.saffron
2019-10-07 22:52 ` lourens [this message]
2019-10-08 17:55 ` [ruby-core:95281] " shevegen
2019-10-08 19:28 ` [ruby-core:95282] " eregontp
2019-10-09 10:49 ` [ruby-core:95289] " sam.saffron
2019-10-09 11:00 ` [ruby-core:95291] " lourens
2019-10-16 5:52 ` [ruby-core:95353] " ko1
2019-10-17 21:16 ` [ruby-core:95404] " sam.saffron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-81948.20191007225247.dca875cb93e6b494@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).