ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: hanmac@gmx.de
To: ruby-core@ruby-lang.org
Subject: [ruby-core:90517] [Ruby trunk Feature#15408] Deprecate object_id and _id2ref
Date: Thu, 13 Dec 2018 16:01:44 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-75676.20181213160143.ea447752bdc2a39f@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15408.20181213005326@ruby-lang.org

Issue #15408 has been updated by Hanmac (Hans Mackowiak).


i hope you don't plan to mess with the VALUE type too

i jumped through many loops to get it right. I connected the Ruby GC with the Object handing from wxWidgets.

* the wx Object holds a Holder Type which has the Ruby value inside
* the Ruby value holds a pointer to the wx Object inside
* then there is a RefCounter added, (so some are extra protected)
* and i added the RubyHash as holder marked as global so as long as the Values stays in this map, they are not freed

=> Result:

* For as long as the wx Object lives, the Holder Object inside it is alive too
* When the wx Object gets deleted, the older object is deleted too, that does decrease the ref count, which when reaching zero does remove it from the Hash.
* this does allow the ruby side allow the object to be freed too.

And yeah there is protection in Case the wx Object is deleted before the ruby Object, in that case the functions throw an Exception


----------------------------------------
Feature #15408: Deprecate object_id and _id2ref
https://bugs.ruby-lang.org/issues/15408#change-75676

* 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/

  parent reply	other threads:[~2018-12-13 16:01 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 ` [ruby-core:90514] " eregontp
2018-12-13 15:36 ` [ruby-core:90515] " muraken
2018-12-13 15:46 ` [ruby-core:90516] " headius
2018-12-13 16:01 ` hanmac [this message]
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-75676.20181213160143.ea447752bdc2a39f@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).