ObjectSpace reveals order?

[Todd Benson]

If I do...

ObjectSpace.each_object { |o| puts o; gets }

will it give me the consecutive order of the loading of the objects
(i.e. the time order that memory is allocated on the heap)? Or is it
a tree structure underneath or something strange like that?

Why do I get String objects right off the bat like...

' does not evaluate to a gem specification


This appears to be source that the interpreter ran and outputted.
I see it on a WindowsXP machine using the 1.8.6 one-click installer.

Todd

P.S.

I understand that this question is hard to answer exactly because you
have to create objects to read the objects you have.

 

[Wilson Bilkovich]

If I do...

ObjectSpace.each_object { |o| puts o; gets }

will it give me the consecutive order of the loading of the objects
(i.e. the time order that memory is allocated on the heap)? Or is it
a tree structure underneath or something strange like that?

Why do I get String objects right off the bat like...

' does not evaluate to a gem specification


This appears to be source that the interpreter ran and outputted.
I see it on a WindowsXP machine using the 1.8.6 one-click installer.

ObjectSpace has everything. Including the String objects that are
sitting around in memory, waiting for you to (in this case) someday
try to load a faulty RubyGem.

It's true that ascending object ids indicate creation order, but I
doubt it would be a good idea to rely on that. Not every Ruby
implementation handles them the same way. object_ids are meant to be
unique, and nothing else.

 

[Todd Benson]

ObjectSpace has everything. Including the String objects that are
sitting around in memory, waiting for you to (in this case) someday
try to load a faulty RubyGem.

It's true that ascending object ids indicate creation order, but I
doubt it would be a good idea to rely on that. Not every Ruby
implementation handles them the same way. object_ids are meant to be
unique, and nothing else.

Thanks for the answer. I think I understand a tiny bit how the Ruby
memory is allocated. I was just wondering if it was a question of
when. But, as you say, every implementation may be different. The
question arose out of a couple of things out of other threads. I
started thinking about code obfuscation, and also whether you can --
within Ruby -- hold on to all interpreted source if need be (while
recalling some other threads on the topic). Then I started thinking
about things like, if you do a count (within the process), you'll have
to allocate memory just to see what's going on in an already volatile
environment. I suppose I'll have to read up on GC stuff.

I'm personally not a big fan of obfuscation, but I'm starting to see
how it could be accomplished (legally) without hurting anyone's
feelings.

<sidenote>the jury is still out for me on ethicality</sidenote>

Todd

 

[Eric Hodel]

If I do...

ObjectSpace.each_object { |o| puts o; gets }

will it give me the consecutive order of the loading of the objects
(i.e. the time order that memory is allocated on the heap)?

Well, its kinda backwards*:

$ cat test.rb
items = ['a', 'b']

ObjectSpace.each_object do |o|
p o.object_id => o
end

$ ruby test.rb | head -3
{1001920=>"b"}
{1001930=>"a"}
{1001940=>["a", "b"]}

[] was allocated first, then 'a', then 'b', not the other way around.

* This example was too small to invoke the garbage collector, so it
will be in reverse order. With garbage collection you aren't
guaranteed any ordering.

Or is it a tree structure underneath or something strange like that?

You can infer the structure of ruby's heap if you make enough
objects. Replace items = ['a', 'b'] with ('a'..'aaa').to_a and add
GC.disable and you'll see something like:

{987780=>"aaa"} # <-- end (bottom) of first heap
{987800=>"zz"}
{987820=>"zy"}
[...]
{1035860=>Kernel}
{1035900=>Class}
{1035910=>Module}
{1035920=>Object} # <-- start (top) of first heap
{1820790=>"Object"} # <-- last used address of second heap
{1820800=>"Object"}
{1820810=>"1035920"}
{1820820=>"{1035920=>Object}"}
[...]
{1828610=>"1022660"}
{1828620=>"{1022660=>\"Errno::EREMOTE\"}"}
{1828630=>{1022660=>"Errno::EREMOTE"}} # <-- start (top) of second heap

Ruby's heaps look something like:

heaps = [
[ ... ], # objects live in here
... # more arrays of objects, as necessary
]

This was on OS X.

Why do I get String objects right off the bat like...

' does not evaluate to a gem specification

You have RUBYOPT=-rubygems

 

[Todd Benson]

If I do...

ObjectSpace.each_object { |o| puts o; gets }

will it give me the consecutive order of the loading of the objects
(i.e. the time order that memory is allocated on the heap)?

Well, its kinda backwards*:

$ cat test.rb
items = ['a', 'b']

ObjectSpace.each_object do |o|
p o.object_id => o
end

$ ruby test.rb | head -3
{1001920=>"b"}
{1001930=>"a"}
{1001940=>["a", "b"]}

[] was allocated first, then 'a', then 'b', not the other way around.

Ok, logistically this makes sense. I see.

* This example was too small to invoke the garbage collector, so it
will be in reverse order. With garbage collection you aren't
guaranteed any ordering.

Or is it a tree structure underneath or something strange like that?

You can infer the structure of ruby's heap if you make enough
objects. Replace items = ['a', 'b'] with ('a'..'aaa').to_a and add
GC.disable

OK. Got ya.

Ruby's heaps look something like:

heaps = [
[ ... ], # objects live in here
... # more arrays of objects, as necessary
]

This was on OS X.

Why do I get String objects right off the bat like...

' does not evaluate to a gem specification

You have RUBYOPT=-rubygems

Thanks!

Todd