On Sep-08, Leopold Toetsch wrote:
I don't know why Storable.xs is using a general HV for mapping an address to an integer (more isn't needed to serialize all IMHO - Dan's next_for_GC approach doesn't provide more info). Perl5 does convert the address to a string and uses all weirdness of hv.c code. This isn't necessary for this special kind of problem.
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 (or some variant, like index of the pmc in its arena, added to/or-ed with some base id for the arena itself)?
A down side to using the address as a key is that it would cause even the simplest serialization to have nondeterministic (or at least unpredictable) output, which certainly makes testing more difficult.
And for the flag, have arenas preallocate a bit vector of seen flags for all their PMCs? (Or if you have the arena base ids, then you can have a single bit vector for all arenas.)
Consider concurrent serialization from multiple threads. The seen hash (table, whatever) is local to the serialization, and thus thread-safe. The programmer can guarantee that the traversed structures are not concurrently updated—the runtime flatly cannot. Any global structure is inherently not thread-safe. Furthermore, global structures are persistently extant, and must be paid for continually. Most programs will never serialize even one object graph, much less spend any significant portion of their CPU time in serialization.
—
Gordon Henriksen [EMAIL PROTECTED]
