On Sun, 26 May 2002, Peter Gibbs wrote:
> "Mike Lambert" wrote:
>
> > I know Dan's proposed solution has already been committed, but I'd
> > like to add my support for this. In addition to providing a counter per
> > opcode to ensure that we don't prematurely GC data, this field could also
> > be reused to calculate the generation of a particular buffer, to help sort
> > it into a correct generational pool (if/when we do get that).
I'm sure it's been discussed before somewhere, but why can't we guarantee
that we only do GC runs between ops? Each op would just have to guarantee
that all of its persistent data is reachable before it returns. It seems
like this would avoid the need for a neonate flag entirely.
As for the generation-sorting, it probably wouldn't require a counter.
The way most generational collectors work is that each time an object in a
younger pool is copied, it gets moved to an older pool. So you don't care
about an object's absolute age, but only the number of collections it has
survived, and you know this implicitly by what pool it's in.
> Perhaps a few volunteers could add the patch below and do before and after
> mops, life, whatever benchmarks and post the results?
These are compiled without optimization, so YMMV, but it does seem to have
a significant effect:
life: 3.7% longer
mops: 21% longer
> frequency of DOD runs, since these are quite slow.
Part of the slowness of DOD runs could be due to the fact that
buffer_lives() isn't getting inlined outside of resources.c. Adding the
function (as inline static) to include/parrot/resources.h gets it inlined
everywhere (particularly hash.c), which may help.
> As an alternative to this, I am currently testing a scheme using flags, so
> that the memory allocation system can request that a DOD run occur at the
> next suitable opportunity, and possible vice versa.
This sounds like a good thing, but I'm not sure how to apply the "vice
versa" operator.
> > Another proposal is to walk the C stack. In runops (or some similar
> This is more in line with standard GC systems, which have no option since
> the program is assumed to be non-cooperative.
AFAIK the only reason to do this ("conservative collection") is if you
absolutely have to, i.e. if you have no idea where your pointers are.
Since we do, I'm not sure why we would want to go to this extra level of
pain. Although it turns out that the Rice Scheme implementation uses the
Boehm conservative collector, even though they should know a lot about
their memory layout -- probably because it's easier than writing their
own.
/s
