[Sorry this has taken so long (as has the rest of my replies to the list).
Between work and the LL1 workshop it's been busy]
At 11:59 PM 11/12/2001 -0500, Michael L Maraist wrote:
>1)
>Are we allowing _any_ dynamic memory to be non-GC-managed?
Yes. We'll have the case where some memory must be pinned essentially
permanently, generally for external use. (Either extensions need it, or
we've handed it off to the system and it'll have to pin. (Think I/O buffers))
Also if someone does a:
$foo = " " x 10000000;
I think we'd like to grab a single chunk of pinned memory for $foo so it
doesn't get collected and potentially copied around. Yech.
>2)
>Can we assume that a "buffer object" is ONLY accessible by a single
>reverse-path-to-PMC?
No. Multiple PMCs can point to a single PMC or buffer object.
>3)
>I believe Dan said that we _could_ assume that PMC's were unmovable, but are
>we requiring this? This is related to the next question.
At the moment we're requiring PMCs be unmoveable. I think we should relax
that so that only PMCs that are used by extensions are unmoveable. It'll
make generational collection easier, I think.
We can't necessarily move a PMC that an extension has, since we don't know
all the places that the pointer to it live, and we'd need to update them
all when we moved them. (We can't even force the extension to tell us the
address a PMC pointer is stored at, since we can't then know if a
third-party extension's made a copy of the PMC pointer somewhere)
>4)
>Are _all_ handles (PMC's, Strings, or whatever) that serve as root-set
>elements dynamically allocated?
Yes.
>Or can c-code declare PMC-structs instead of
>PMC-structs-pointers?
No. That's not going to be allowed. We can't change the PMC structure and
maintain binary compatibility if we do that.
>a heterogenous pool of handles would complicate things (and
>disqualify many desirable algorithms).
Welcome to the fun of the world. :)
We have a heterogenous pool of handles. You have, as root set, at least:
*) The main package hash
*) The register set
*) The foreign access registry
*) The savestack
If it helps, the arena structure (which we don't have defined yet) will
look like:
struct PMCArena {
struct PMC PMCs[ARENA_SIZE];
void *PMC_gc_bit[ARENA_SIZE];
}
which is to say that an arena will have at least a void pointer handy per
PMC in an arena. If you need more we can do that, though I'd like to keep
the overhead as low as feasable. It's separate from the main PMC structure
because we only need it for a DOD run. (If its separate, it won't take up
space in a cache line we could otherwise make use of)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
