> > > I'm not sure on this one. Given that a compacting collector needs
> > > several times as much RAM available as in use to be efficient, and that
> > > a reference-counting collector probably gives no more fragmentation than
> > > malloc, it's hard to say which way locality would go.> > No joke sometimes I agree and malloc is just 'good enough'
> Heap fragmentation is quite a big problem with malloc, you can see
> that just by
> the number of malloc and other memory allocation frameworks that have
> been
> written over the years.> > > The traditional objection to reference counting is that you spend a lot
> > > of time adjusting reference counts. But with CPUs are so much faster
> > > than RAM nowadays, that may matter less. Anyways, for more than you
> > > ever wanted to know about GC, here's a slightly-dated but still
> > > excellent survey paper:> > >ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps
> > Thank you. I've wondered about this, myself, as, to my limited
> > knowledge, a generational GC would need to 'alias' everything that's
> > allocated (so it could move them to different generations), which would
> > involve a memory redirection. I could be wrong.> You are. Generational GCs (I wrote one for Rubinius) do not need
> double
> the memory as I assume you're implying. They use what's called a write
> barrier
> (a small chunk of code) that runs whenever an object reference is
> stored
> in another object. This code is very small and simply updates a small
> table.
> That table is used by the GC to make sure that it runs properly and
> can
> update object references as objects move around.On a completely unrelated note, I was wondering... how did you manage
to keep compatibility with existing C extensions without requiring the
developer to explicitly set write barriers, in some cases?
The key is that C extensions don't have direct access to object
references. A C extension accesses all objects via a handle table. A
handle is what a C extension sees as an object. This lets the GC
mutate objects (which are also in the handle table) but keep the
handles at constant addresses (so they can be stored on the C stack).
The big problem with this approach is the RARRAY(), RSTRING(), etc
macros, that access an object directly as C data structure. Thats the
main reason for trying to move MRI away from using these macros and to
using something that looks like a function call that we in rubinius
can implement differently.
- Evan
···
On Nov 11, 6:11 am, Laurent Sansonetti <laurent.sansone...@gmail.com> wrote:
On Nov 11, 2007 9:35 AM, evanw...@gmail.com <evanw...@gmail.com> wrote:
> On Nov 10, 9:45 pm, Roger Pack <rogerpack2...@gmail.com> wrote:
(Sorry for being off-topic.)
Laurent