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.1 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 0D08F20248 for ; Tue, 26 Mar 2019 18:01:36 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C0EBE121861; Wed, 27 Mar 2019 03:01:31 +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 55326121056 for ; Wed, 27 Mar 2019 03:01:30 +0900 (JST) Received: by filter0005p3iad2.sendgrid.net with SMTP id filter0005p3iad2-29887-5C9A68F9-27 2019-03-26 18:01:29.299036114 +0000 UTC m=+687929.339218769 Received: from herokuapp.com (unknown [18.209.111.39]) by ismtpd0068p1mdw1.sendgrid.net (SG) with ESMTP id hubnGqB5Ruip2st7SAS-nw for ; Tue, 26 Mar 2019 18:01:29.257 +0000 (UTC) Date: Tue, 26 Mar 2019 18:01:29 +0000 (UTC) From: headius@headius.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 67486 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15711 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: =?us-ascii?Q?FFqrkVUH+vvTO0v2jw+akFtsx0ctu2v3V2wlBAc+sNqtcZwGX2hK9mDvGMF5ol?= =?us-ascii?Q?2kTWJh46c4RvZ9HeK96PBv6u9awiQkj=2FGF=2F+5ZS?= =?us-ascii?Q?US7IQdBJjX=2F4mvxgMoP0l+pBFKfn1P1LzhLhJF4?= =?us-ascii?Q?Fia1x8tAMzEZFiJqCoURXkJ+CegGiGsYud2oR1c?= =?us-ascii?Q?0s0=2FKEKJpbDAac9LD5kX2dzvkyhE9LeZRgQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92000 Subject: [ruby-core:92000] [Ruby trunk Bug#15711] Remove use of _id2ref from DRb 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 #15711 has been updated by headius (Charles Nutter). I have not written up a patch based on a reference queue, but it would basically just use the `IdWeakRef` class and the `_cleanup` method from the `IdHash` example collection in my "weakling" library: https://github.com/headius/weakling/blob/master/lib/weakling/collections.rb This implementation polls the reference queue on each "clean", which will be a no-op when there are no vacated references in the queue. Compare to the full Hash scan in the supported weakref version. In order to use the more efficient impl, the weakref library would need to support reference queues. ---------------------------------------- Bug #15711: Remove use of _id2ref from DRb https://bugs.ruby-lang.org/issues/15711#change-77329 * Author: headius (Charles Nutter) * Status: Assigned * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- This issue relates to https://bugs.ruby-lang.org/issues/15408 DRb uses `_idref` internally to implement a weak map, and this issue seeks to replace that code with an implementation that does not use `_id2ref`. We will be deprecating `ObjectSpace._id2ref` in the near future since it fails to work like people expect (when implemented as a pointer address) or adds memory and invocation overhead to `object_id`. An initial patch for this is provided by JRuby, which implements `object_id` using a monotonically-increasing value, and only allows `_id2ref` use with a command line flag. https://github.com/ruby/ruby/compare/trunk...jruby:jruby-ruby_2_6_0#diff-e979bf2f831d9826629559b8628809e9 This implementation uses the stdlib `weakref` to implement a simple weak map, and it would be suitable as an implementation for now. However there's some inefficiency here because it has to periodically "clean" the hash of vacated references by scanning all entries. There are two more efficient implementations that require additional work: Alternate 1: Use `ObjectSpace::WeakMap`, which is an opaque VM-supported implementation of a weak Hash. Unfortunately I don't think `WeakMap` has ever been blessed as a public API, and since we're rapidly moving standard libraries to gems, it would not be appropriate to use an internal API. So, we can either make WeakMap an official part of the public standard API, or do alternate 2. Alternate 2: Add weak reference queues to the weakref API, so users can implement their own efficient weak maps. Some of this has been discussed (at great length) in https://bugs.ruby-lang.org/issues/4168, and the JRuby team has supported the [weaklink](https://github.com/headius/weakling) gem for many years (which provides a WeakRef+RefQueue implementation for JRuby). The original patch works well for small numbers of remoted objects. -- https://bugs.ruby-lang.org/