On 9/28/07, Wilson Bilkovich <wilsonb / gmail.com> wrote:
> On 9/28/07, Todd Benson <caduceass / gmail.com> wrote:
> > 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.

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