At 03:19 AM 11/3/2001 -0500, Michael L Maraist wrote:
>On Friday 02 November 2001 05:27 pm, Dan Sugalski wrote:
>I hope rellocation can be handled efficiently. I have these images in my
>head of multiple references to the same memory structure.. Relocating would
>involve finding each and every referrer. That's a many to many association
>O(n^2). Perhaps you suggest that PMC's themselves are not relocatable, and
>thus only a single PMC referes to each object in relocation-space.
The current plan is to have PMCs and buffer objects be non-moveable, so if
multiple things wanted to point to a buffer they'd really point to the
buffer object or the PMC. It's possible that PMCs and buffer objects will
be relocatable too, but that's more work for the GC subsystem. Plus it
places more restrictions on non-interpreter code caching pointers to things.
Handling updating the pointers themselves isn't a big deal. That's a
long-solved problem for copying collectors.
>Sounds
>like multiple heaps to me, but then there are advanced concepts like aliasing
>/ shared data-structures, etc.
I'm expecting we'll have multiple heaps, yep--if only so we can implement a
generational GC system. Otherwise we need a pretty hefty temporary memory
space.
> > For a buffer to be considered 'live' it must be pointed to by a PMC either
> > directly or via a single level of indirection. (If the PMC points to a
> > buffer object that has an array of buffer pointers in it) For a PMC to be
> > considered live it must be reachable via the interpreter's root set.
>
>I'm missing the implications of being "live" or not.
If a buffer's not live, we ignore it and potentially stomp on it when we're
allocating memory or going a compaction of the heap.
> > There will be a mechanism to register PMCs with the interpreter to note
> > they're pointed to by something that the interpreter can't reach. (For
> > example, a structure in your extension code, or via a pointer stashed in
> > the depths of a buffer object, or referenced by another interpreter) This
> > "foreign access" registry is considered part of an interpreter's root set.
>
>Does this mean a flag exists such that when XS-code references a PMC it is
>set?
Nope. It means that if your extension code has something like:
static PMC *cache;
up at the top, you'd darned well better do a:
Parrot_PMC_Register(cache);
to tell us you're stowing away a pointer to a PMC, otherwise we'll
GC/destruct the thing.
>Lastly, is there any facility for private dynamic memory w/in XS code.. Such
>as algorithms that don't utilize PMC structures; especially parrot-ignorant
>algorithms. I assume they'd need heap-space avoided by the GC.
Yep, traditional alloc/free memory will be available, as will immoveable
memory (for those cases where you're passing it to an external library or
interrupt handler or something).
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
