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=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, 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 84ED320A1E for ; Thu, 13 Dec 2018 01:47:15 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 3156612110B; Thu, 13 Dec 2018 10:47:13 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 7E73F120A1A for ; Thu, 13 Dec 2018 10:47:10 +0900 (JST) Received: by filter0078p3iad2.sendgrid.net with SMTP id filter0078p3iad2-22450-5C11BA1A-2F 2018-12-13 01:47:06.930974149 +0000 UTC m=+178627.352838294 Received: from herokuapp.com (ec2-54-197-181-61.compute-1.amazonaws.com [54.197.181.61]) by ismtpd0019p1iad2.sendgrid.net (SG) with ESMTP id c4RKpJb4SquRk4T-pMsqWg Thu, 13 Dec 2018 01:47:06.934 +0000 (UTC) Date: Thu, 13 Dec 2018 01:47:08 +0000 (UTC) From: headius@headius.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65881 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15408 X-Redmine-Issue-Author: headius X-Redmine-Sender: headius 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4KJnKkw3wOeQn0p18QhXdYNyxlbyI4dV4Vaw TuQE9AOR8Ytgc7vGSf6T7MBsjngvj1utPjzML6cuLOGOeLlYSAJ/Ubz2HKwBddygc3RkF4gShI/cuP KR3ULkK6a3ZPdnahpRNjNtWGc6B9SRmP3aEtPhCmPeATZXPQumbcUcc6gw== X-ML-Name: ruby-core X-Mail-Count: 90474 Subject: [ruby-core:90474] [Ruby trunk Feature#15408] Deprecate object_id and _id2ref 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 #15408 has been updated by headius (Charles Nutter). > These methods show too much internals (bare C pointer values). It is possible to implement them as lazy monotonically increasing integers, but you either have to accept that they will overflow into bignum or wrap around at some point. JRuby has opted for wrap-around currently, so even our impl is not truly idempotent. > ...they should be hidden from the core API. I'd love to see a hard break sooner than later, but I think deprecation will quickly get the Ruby community to clean up uses. It would also be a good idea for WeakMap to become a standard, public class rather than one hidden inside ObjectSpace, since that's typically the use case for `_id2ref`. Libraries can assign their own keys for objects in whatever way they choose (e.g. monotonically increasing integer). ---------------------------------------- Feature #15408: Deprecate object_id and _id2ref https://bugs.ruby-lang.org/issues/15408#change-75632 * 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/