So I would guess that Ruby memory allocation is relatively expensive?
Certainly nowhere near as fast as allocating memory off of the "end"
of the heap or the stack, right? Does it have to search a free list of
blocks itself or does it delegate allocation to the system's malloc()
implementation?

It's tricky doing the interop with the CLR since things like boxed
value type objects *can* be moved in memory, so I need create a pinned
GCHandle object to keep the GC from moving the object (this is also
bad as you could imagine since it leads to heap fragmentation). So
after spending most of the day thinking about the CLR side of the
house, I was a bit surprised to find that Ruby doesn't move objects
around.

This makes me a bit happier in a way since I don't have to worry about
the issues on both sides of the house, but since I figured out how to
do it on the CLR side, I was hoping to reuse that new-found experience
on the Ruby side :)

Thanks for the insights.
-John
http://www.iunknown.com




> No ruby does not move objects in memory. As to how horrible that
> would be if it did, there are GCs that do work like this (Copying
> GC). Believe it or not there are speed advantages to copying gcs in
> that the algorithm has runtime  proportional to the number of
> reachable objects, rather than the size of the heap like mark-and-
> sweep (which is what ruby uses). Copying collectors also compact the
> the memory, reducing fragmentation. A copying GC would be difficult
> in the current ruby implementation since a copying gc cannot really
> be conservative (it has to change things in the root set), and ruby
> uses the C stack so it is difficult to be sure if something is
> definitely _not_ a pointer. With mark-and-sweep false positives are
> ok, since nothing ever gets moved. With a copying gc it could mistake
> an int on the c stack for a pointer "collect" the "object" it
> "pointed" to and then change the value. Which of course would be the
> cause of many odd and subtle bugs in ruby code.
>
>
>