Memory Model in Ruby

Question

How memory is managed in ruby. For Ex: if we take the C program during execution, the following is the memory model. Similar to this how memory is handled in ruby.

  C:
                       __________________
                        |                |
                        |      stack     |
                        |                |
                        ------------------
                        |                |
                        |   <Un Allocated|
                        |       space>   |
                        ------------------
                        |                |
                        |                |
                        |       Heap     |
                        |                |
                        |                |
                        __________________
                        |                |
                        |       data     |
                        __________________
                        |       text     |
                        __________________

Ruby: 

              ?

Extrinsic

There is no such thing visible to a Ruby program. All this is abstracted by the interpreter. – Zaratite

@Zaratite Atleast any Conceptual diagram? – Extrinsic

A single box labeled "memory"? – Zaratite

sitepoint.com/ruby-uses-memory – Comfortable

Answer 1

There is no such thing as "memory" in Ruby.

Class#allocate allocates an object and returns that object. And that is the entire extent of interaction that a programmer can have with the object space subsystem.

Where that object is allocated, how it is allocated, if it stays at the same place in memory or moves around, none of that is specified or observable. For example, on MagLev, an object may actually not be allocated in memory at all, but on disk, or in another computer's memory. JRuby, IronRuby, Opal, Cardinal, MacRuby, etc. "outsource" their memory management to a third party, they literally don't even know what's happening to their memory.

A Ruby implementation may use a separate stack and heap, it may use a heap-allocated stack, it may not even use a stack at all (e.g. Cardinal).

Note: the ObjectSpace module allows a limited amount of introspection and reflection of the object space. In general, when I say something is "impossible" in Ruby, there's always an implicit caveat "unless you use reflection". However, even ObjectSpace does not leak any information about the organization of memory.

In YARV, there is also the objspace library and the GC module, which provide internal implementation details about YARV. However, they are private internal implementation details of YARV, they are not even guaranteed to exist in other implementations, and they may change at any time without notice even within YARV.

You may note that I didn't write anything about garbage collection! Well, actually, Ruby only specifies when objects are referenced and when they aren't. What to do with un-referenced objects, it doesn't say. It makes sense for an implementation to reclaim the space used by those unreferenced objects, and all of them do to some degree (e.g. older versions of YARV would not reclaim unreferenced Symbols), but it is not required nor specified. And all implementations use very different approaches. Again, JRuby, IronRuby, Opal, Cardinal, MacRuby, Topaz, MagLev, etc. "outsource" that problem to the underlying platform, Rubinius uses a generational, copying, moving, tracing collector based on the Immix collector, YARV uses a simple mark-and-sweep tracing collector.

Harkness