From: Laurent Sansonetti <laurent.sansonetti@...>
Date: 2007-11-11T23:11:09+09:00
Subject: Re: JRuby performance questions answered

On Nov 11, 2007 9:35 AM, evanwebb@gmail.com <evanwebb@gmail.com> wrote:
> On Nov 10, 9:45 pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> > > 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?

(Sorry for being off-topic.)

Laurent