On Mon, 5 Nov 2001, Dan Sugalski wrote:
> At 12:23 AM 11/5/2001 -0800, Brent Dax wrote:
> >Michael L Maraist:
[reordered for clarity]
>
> > But I hear that we're not relying on an
> > integer for
> > reference counting (as with perl5), and instead are mostly
> > dependant on the
> > GC.
>
> You're conflating dead object detection with GC. Don't--the two things are
> separate and if you think of them that way it makes things clearer.
Ok, this clarifies things a bit. I know you're purposefully standing
back from the details, though that's conflicting with my head-burried
among the trees not being able to accept that it's all part of a
forest. You're saying that the dod (dead object detector) has to have
intimate knowledge of
the parrot internals, while the gc is part of the memory-manager
black-box. The main reason I joined the two was to reduce the number
of passes in my presented algorithm.
> >First of all, how are arrays of arrays of arrays handled?
>
> You'll have a PMC who's data pointer points to a buffer of PMCs. That works
> fine--we'll tromp through the buffer of PMC pointers and put them on the
> list of live PMCs and GC them as needed.
Just for clarification, does this mean that (depending on the
algorithm) the dod will check if the PMC is an
array, and thus recurse into the object buffer? Or does this mean that
at array creation time, the nested PMCs are added to some top-level
list of live PMCs?
>
> ># Now I'm
> ># still in favor of some form of reference counting; I think
> ># that in the most
> ># common case, only one data-structure will reference a PMC and
> ># thus when it
> ># goes away, it should immediately cause the deallocation of
> ># the associated
> ># object-space (sacraficing a pitance of run-time CPU so that
> ># the GC and free
> ># memory are relaxed).
>
> Don't underestimate the amount of CPU time taken up by reference counting.
> Amortized across the run of the program, yes, but not at all insignificant.
> Also horribly error prone, as most XS module authors will tell you.
> (assuming they even notice their own leaks, which many don't)
With respect to XS memory leaks, I wasn't suggesting that ref-flagging
superceed explicit dod, but provide an optional and
efficient quick-check. The suggestion was that by checking a flag we more
quickly free resources. Otherwise for for-loops that alloc/free data, this can
quickly starve memory (and regularly invoke the gc), whereas the
ref-flagging would successfully reuse the same memory space each time
(conserving cache-space as well).
While I was mostly considering using the API to attach references which
would avoid the XS mem-leakage, I suppose even a simple flag can be abused.
With respect to "cpu" time, I'd be curious to see benchmarks. I'd
agree that adding an if-statement to every assignment adds overhead
(especially since it's an unpredictable hardware branch). But I can't
think of a good dod that's not O(n). Under heavy
memory loads, I'd argue that (short of always requesting more memory)
relying exclusively on GCs will always be slower than ref-counting:
For every m allocations (with sufficiently large m):
o with ref-counting/flagging you have m maintanance operations
o with dod/gc, you have roughly 1 triggered gc with O(n) objects to
navigate through.
Note that for sufficiently large memory requests, both will invoke
the gc. I focused mainly on the tight inner loop of allocs/frees.
Still, I'd agree that if XS-code can't be trusted with a modified form
of reference-management, then gc does make developers lives easier.
-Michael
