Okay, I've been pondering complex data structures, garbage collection, and
cache coherency for the past few days. (Between this, Unicode, the regex
engine, and backwards compatibility, I'll be easy to spot at TPC 5.0. Just
look for the tall guy wearing the wraparound canvas sweater...) Because of
that, I'm wondering whether it'd be in our best interests to have some sort
of split data structure for PMCs.
We're going to have the advantage of *knowing* that all our PMCs will be
allocated out of arenas, which means we can safely partition the arenas
into pieces that correspond to pieces of the PMC. For an example, it would
mean we could do:
struct arena {
struct base_PMC[4096];
long PMC_GC_data[4096];
}
and know that arena.PMC_GC_data[12] corresponded to arena.base_PMC[12].
This makes sense for pieces of a structure that are reasonably little used,
like the GC info. (Which is used only by the garbage collector and should,
I'd hope, be accessed significantly less than the rest of the PMC data)
This works out well for the garbage collector, since it will be dealing
with arenas as arrays of PMCs. What I'm not sure of is whether this would
benefit us with other pieces of a PMC. I'm thinking that passing around an
arena address and offset and going in as a set of arrays is probably
suboptimal in general, but I'm curious as to whether anyone has any hard
experience with this sort of thing before I delve in any deeper.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
