32

When the p function is used to print out an object, it may give an ID, and it is different from what object_id() gives. What is the reason for the different numbers?

Update: 0x4684abc is different from 36971870, which is 0x234255E

>> a = Point.new
=> #<Point:0x4684abc>

>> a.object_id
=> 36971870

>> a.__id__
=> 36971870

>> "%X" % a.object_id
=> "234255E"
nonopolarity
  • 146,324
  • 131
  • 460
  • 740

3 Answers3

53

The default implementation of inspect calls the default implementation of to_s, which just shows the hexadecimal value of the object directly, as seen in the Object#to_s docs (click on the method description to reveal the source).

Meanwhile the comments in the C source underlying the implementation of object_id shows that there are different “namespaces” for Ruby values and object ids, depending on the type of the object (e.g. the lowest bit seems to be zero for all but Fixnums). You can see that in Object#object_id docs (click to reveal the source).

From there we can see that in the “object id space” (returned by object_id) the ids of objects start from the second bit on the right (with the first bit being zero), but in “value space” (used by inspect) they start from the third bit on the right (with the first two bits zero). So, to convert the values from the “object id space” to the “value space”, we can shift the object_id to the left by one bit and get the same result that is shown by inspect:

> '%x' % (36971870 << 1)
=> "4684abc"

> a = Foo.new
=> #<Foo:0x5cfe4>
> '%x' % (a.object_id << 1)
=> "5cfe4"

Note: The details about object_id were correct at the time (2010), but aren't anymore after newer Ruby versions have decoupled object_id from memory addresses. Now the answer is more along the lines "because object_id is generated on demand". See comments.

Arkku
  • 41,011
  • 10
  • 62
  • 84
  • those ruby-doc.org links are dead now :-( – AlexChaffee Oct 10 '11 at 15:04
  • @AlexChaffee I couldn't find directs links to method sources anymore, edited the post with indirect links. – Arkku Oct 11 '11 at 01:46
  • 1
    This answer is no longer correct for Ruby versions 2.7 and greater. [This blog post](https://jemma.dev/blog/gc-object-id) gives a great explanation. Recent Ruby versions have decoupled `object_id` from the object's actual memory address. – ulysses_rex Aug 10 '23 at 13:14
  • @ulysses_rex Thanks, you are correct. I have made a note of this in the answer (but left it mostly as it was for historical reference). – Arkku Aug 11 '23 at 00:23
0
0x234255E

=>36971870

It's not different, it's the hexadecimal representation of the memory address:-)

Robbie
  • 715
  • 9
  • 19
0

Ruby version 2.7 decoupled the object's object_id from the memory address itself, so you can't transform an object_id into a memory address or vice versa. In fact, the object's actual address can change while its object_id remains the same.

That said, depending on your Ruby version, the ObjectSpace module might be able to return an object's memory address. Note: this library changes frequently, so most likely you should only use it in the console.

# Using Ruby version 2.7.8 -- this code may not work in later versions!

require "objspace"
require "json"

object = Object.new
#=> #<Object:0x00007ff174981a08>

object_internals_json = ObjectSpace.dump(object)
#=> "{\"address\":\"0x7ff174981a08\", \"type\":\"OBJECT\", \"class\":\"0x7ff18d991250\", \"ivars\":0, \"memsize\":40, \"flags\":{\"wb_protected\":true}}\n"

JSON.parse(object_internals_json)["address"]
#=> "0x7ff174981a08"
ulysses_rex
  • 330
  • 3
  • 16