Re: gencgc performance and soft-real time

<satyr_22901@xxxxxxxxx> top-posts:

> compiler support for it.  On the x86 the garbage collector is a
> conservative collector so it cannot assume that everything that looks
> like a pointer is in fact a pointer and modify the values, so it leaves
> all of the data in place--otherwise it would risk changing an integer

You are wrong.  The x86 gencgc is a mostly copying collector with
exact collection in dynamic and static spaces (i.e. most of memory).
The only conservative collection going on is when it scavenges the
call stack: pages pointed to by potential pointers (potentially
pointed to?) are advanced to the next generation and marked dont_move
so that they won't be relocated.

Luke writes:

>> > My first thought was to put a write barrier over static space.
>> While I
>> > was still struggling to make that work (but never did), Dan Barlow
>> > suggested a more holistic approach -- why do we have so many
>> objects
>> > in static space, and could we not put them into a "tenured"
>> generation
>> > that doesn't get GC'd instead? That would give us a write-barrier
>> for
>> > free.

I'm still interested in that latter approach: most of the support is
there already in gencgc and in theory it just needs a couple of
variables changing.  In practice I'm sure it'll be more complicated ...

This would mean that static space could get a whole lot smaller: it
would only be used for the twenty or so variables/functions that we
need addresses of C.  The question mark is that - at least in SBCL, I
haven't checked in CMUCL - purify can actually free more memory than a
full gc does, so whatever extra it does needs to be looked at.  Right
now I'm otherwise occupied (trying to find why interrupt-thread of a
consing process fails on average one gc in 200), and don't know when
I'll get to look at this.


-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources

pgpKVvpfKUVPg.pgp
Description: PGP signature