From: shevegen@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:95281] [Ruby master Feature#16245] Add interfaces to count and measure size all IMEMO objects
Date: Tue, 08 Oct 2019 17:55:42 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-81959.20191008175541.36aa2ab065c1b5f7@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16245.20191007220247@ruby-lang.org
Issue #16245 has been updated by shevegen (Robert A. Heiler).
Personally I love introspection so I am all in favour of giving ruby people
lots of tools to play with internal. I also liked oldschool evi.rb. :)
I guess this is for koichi to comment e. g. how stable he considers the
gem/code; and possibly also whether the API is wanted in the first place.
And perhaps also whether the name iseq is already an official name or
not, ruby-internal wise (I really don't know, just pointing that out).
As for the name **NonMaterializedInstructionSequences** - I think that name is
too long and complicated. Ideally accessing should be simple, whenever possible,
in my opinion. I am not even sure what a "non-materialized instruction sequence"
is - is that ruby's version of a monoid-endofunctor monad?
IMO, simpler names would be better. Although I guess if the functionality is
what matters, then I guess we may agree that the functionality can be useful.
methodmissing wrote:
> 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.
Yeah, I think I have read similar discussions in the past, also comments made
by matz, koichi and shyouhei, in a different context. Which I guess makes
sense too - less exposure may mean less problems. I am also neutral about the
proposal really, don't mind either way - guess it may be for sam to reason
in favour of it. :-)
Even then, though, I love introspection in general. Ruby is like a closed box
initially, just like on xmas (and the xmas release), and you get the tools to
poke inside and try to find out how it works! \o/
Perhaps if it may help the discussion (not that I contribute much to it),
there could be a discussion for potential problems in this regard, e. g.
pitfalls, problems etc... or it may remain a separate gem, and it may be
evaluated how useful it may be to integrate it into ruby directly. That
discussion has also happened with other code elements / gems in the past,
e. g. martin duerst pointed this out a few times before. But as said, I
am really neutral either way here.
----------------------------------------
Feature #16245: Add interfaces to count and measure size all IMEMO objects
https://bugs.ruby-lang.org/issues/16245#change-81959
* 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/
next prev parent reply other threads:[~2019-10-08 17:56 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 ` [ruby-core:95272] " lourens
2019-10-08 17:55 ` shevegen [this message]
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-81959.20191008175541.36aa2ab065c1b5f7@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).