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=-2.9 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,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 BF5641F405 for ; Sun, 16 Dec 2018 11:00:50 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C1C21120F7C; Sun, 16 Dec 2018 20:00:48 +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 DE6C8120F73 for ; Sun, 16 Dec 2018 20:00:44 +0900 (JST) Received: by filter0061p3mdw1.sendgrid.net with SMTP id filter0061p3mdw1-32013-5C163056-22 2018-12-16 11:00:38.503148883 +0000 UTC m=+125286.960791862 Received: from herokuapp.com (ec2-54-81-240-46.compute-1.amazonaws.com [54.81.240.46]) by ismtpd0052p1mdw1.sendgrid.net (SG) with ESMTP id -_DS1xUJTSGTJbNP1OlI3A Sun, 16 Dec 2018 11:00:38.391 +0000 (UTC) Date: Sun, 16 Dec 2018 11:00:39 +0000 (UTC) From: eregontp@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65967 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15408 X-Redmine-Issue-Author: headius X-Redmine-Sender: Eregon 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS7uz4fF3fOppD13e2ItEoF55+AHJoWlZESfvB 73TD+FqU857f1fqm+QZ4Lfg+V5BBzbGNYN5+AFjippyfdiAX/UOjBbgbUTZGSxEnfZ8gQYWHkdh8Pr rCKbTJhtp2CjDuuBtJBChuhMN6Raz7oH2L7H5CXkAzmz4sFdZXb4lBA0Fw== X-ML-Name: ruby-core X-Mail-Count: 90563 Subject: [ruby-core:90563] [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 Eregon (Benoit Daloze). Target version set to next minor Let's deprecate `ObjectSpace._id2ref` in 2.7 then. I think we also need to address the usage in DRb. cc @seki ---------------------------------------- Feature #15408: Deprecate object_id and _id2ref https://bugs.ruby-lang.org/issues/15408#change-75713 * Author: headius (Charles Nutter) * Status: Open * Priority: Normal * Assignee: * Target version: next minor ---------------------------------------- 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/