Steve Fink <[EMAIL PROTECTED]> wrote:
> On Sep-08, Leopold Toetsch wrote:
>> Parrot has some DOD counters for possibly active PMCs. A simple and
>> probably fix-sized[1] hash based on such a count with just a mapping of
>> {&pmc => id} takes 12 bytes per entry on 32-bit architecures and its
>> really fast.
> It's late so I'm probably being an idiot, but is all that is needed
> (1) a unique id for every pmc address, and (2) whether or not the PMC
> has been visited yet? If so, why not use the address itself for the id
Yep. The address can serve as the ID (it would with Dan's scheme).
> Or is there no simple way of going from a PMC address to its arena?
With ARENA_DOD_FLAGS enabled: GET_ARENA(pmc). When its disabled it would
need arena back pointers or a lookup like C<contained_in_pool()>. Both
methods can generate an index usable for indexing into the bit vector.
But I wouldn't want to use arena memory for the bit vector. This leads
to the same multi threading issues, as Dan's scheme has.
A bit vector instead of the hash allocated on the heap sounds very
promising and space efficient.
> Perhaps it's no win to pollute the cache with chunks of the bit vector
> instead of the actual referenced PMC flagpoles.
clone()/freeze()/dump() pull in the whole PMC. DOD doesn't for the fast
case of just setting the live flag on a scalar. But ...
> ... An
> eighth of a bit per entry ought to be small enough, no?
Yep. Think so.
> I suppose I ought to pay more attention to the conversation (and the
> current code) before butting in with suggestions. I've a feeling I'm
> solving the wrong problem.
No. The idea is fine and would work.
leo
