From: eregontp@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:90514] [Ruby trunk Feature#15408] Deprecate object_id and _id2ref
Date: Thu, 13 Dec 2018 15:23:40 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-75673.20181213152339.30c3ee6911e2e02d@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15408.20181213005326@ruby-lang.org
Issue #15408 has been updated by Eregon (Benoit Daloze).
mrkn (Kenta Murata) wrote:
> Rather, in pycall, I use `object_id` and `_id2ref` for managing wrappers of Python classes and Python modules in Ruby.
> The reason why I use them is I want to reuse existing wrappers, while I don't want to protect the wrappers from garbage collection.
> For this purpose, pycall has mappings from a Python object pointer to an ID of Ruby object, which is a wrapper of the Python object.
> The existing WeakRef can be used for this purpose, but I didn't want to use it because I want to reduce the frequency of object generation.
But then this is exposed to the _id2ref bug, i.e., it could return another wrapper if the wrapper is GC'd and a new wrapper gets the same address.
Then that would probably be a very serious bug exposed to pycall users.
----------------------------------------
Feature #15408: Deprecate object_id and _id2ref
https://bugs.ruby-lang.org/issues/15408#change-75673
* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected.
As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future.
Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap.
The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently.
The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup.
I propose that both methods should immediately be deprecated for removal in Ruby 3.0.
* They do not do what people expect.
* They cannot reliably do what they claim to do.
* They eventually lead to difficult-to-diagnose bugs in every possible use case.
Put simply, both methods have always been broken in MRI and making them unbroken would render them useless.
--
https://bugs.ruby-lang.org/
next prev parent reply other threads:[~2018-12-13 15:23 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-15408.20181213005326@ruby-lang.org>
2018-12-13 0:53 ` [ruby-core:90464] [Ruby trunk Feature#15408] Deprecate object_id and _id2ref headius
2018-12-13 3:55 ` [ruby-core:90482] " Bill Kelly
2018-12-13 4:07 ` [ruby-core:90484] " Bill Kelly
2018-12-13 0:58 ` [ruby-core:90465] " headius
2018-12-13 1:22 ` [ruby-core:90469] " shyouhei
2018-12-13 1:36 ` [ruby-core:90472] " ko1
2018-12-13 1:43 ` [ruby-core:90473] " headius
2018-12-13 1:47 ` [ruby-core:90474] " headius
2018-12-13 1:52 ` [ruby-core:90475] " headius
2018-12-13 2:00 ` [ruby-core:90476] " headius
2018-12-13 2:11 ` [ruby-core:90477] " pdahorek
2018-12-13 2:17 ` [ruby-core:90478] " headius
2018-12-13 2:21 ` [ruby-core:90479] " headius
2018-12-13 4:29 ` [ruby-core:90485] " duerst
2018-12-13 5:00 ` [ruby-core:90487] " shyouhei
2018-12-13 5:36 ` [ruby-core:90490] " headius
2018-12-13 7:11 ` [ruby-core:90496] " ko1
2018-12-13 11:32 ` [ruby-core:90504] " eregontp
2018-12-13 11:54 ` [ruby-core:90505] " shevegen
2018-12-13 13:32 ` [ruby-core:90507] " mame
2018-12-13 13:56 ` [ruby-core:90508] " headius
2018-12-13 13:59 ` [ruby-core:90509] " headius
2018-12-13 14:03 ` [ruby-core:90510] " headius
2018-12-13 14:08 ` [ruby-core:90511] " headius
2018-12-13 14:52 ` [ruby-core:90512] " muraken
2018-12-13 15:05 ` [ruby-core:90513] " headius
2018-12-13 15:23 ` eregontp [this message]
2018-12-13 15:36 ` [ruby-core:90515] " muraken
2018-12-13 15:46 ` [ruby-core:90516] " headius
2018-12-13 16:01 ` [ruby-core:90517] " hanmac
2018-12-13 16:12 ` [ruby-core:90518] " headius
2018-12-15 14:29 ` [ruby-core:90550] " matz
2018-12-16 10:49 ` [ruby-core:90559] " eregontp
2018-12-16 10:57 ` [ruby-core:90561] " naruse
2018-12-16 11:00 ` [ruby-core:90563] " eregontp
2019-01-09 17:46 ` [ruby-core:90950] " eregontp
2019-01-10 23:20 ` [ruby-core:91007] " Charles Oliver Nutter
2019-01-14 7:35 ` [ruby-core:91072] " naruse
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-75673.20181213152339.30c3ee6911e2e02d@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).