On Jan 6, 2004, at 6:42 PM, Luke Palmer wrote:

Jeff Clites writes:
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:

It makes each chunk into a subclass of Buffer like so:

   struct RegisterChunkBuf {
       size_t used;
       PObj* next;
   };

To do that properly, I think you need a pobj_t as the first struct member, like string has:

struct parrot_string_t {
    pobj_t obj;
    UINTVAL bufused;
    void *strstart;
    UINTVAL strlen;
    const ENCODING *encoding;
    const CHARTYPE *type;
    INTVAL language;
};

Ah, no. That's how you create a new type of header. I need nothing more than the simple buffer header. So I make a PObj and stick this struct in its bufstart.

Hmm, okay; I'm mildly confused then, but that's okay--I need to stare at this a bit more. But if you put your struct inside the memory pointed to by the bufstart of a simple buffer header, then I think that compact_pool() is going to expect you to have a Buffer_Tail and such. Since your struct is fixed-size, I would think it would make more sense to make it a new type of header (like Stack_Chunk in stacks.h); but on the other hand, I don't think we COW headers, and we need major COW here. Hmm, still fuzzy.


I want these things to be garbage collected, but DOD doesn't trace the
buffer. I can't seem to find a way to mark the frames without making
the chunks into PMCs (yuck). Is there a way to do this?

I think you'll need to add something to the root set tracing code (probably trace_active_buffers() in src/dod.c). I'm not sure what all of you stuff hangs off of, though.

Did that. That works for the main part, but continuations and who-knows-what-else are going to be holding references to parts of these, so I'd like to mark these automatically.

Yeah, I was on crack--what I said made no sense; of course these are going to be hanging off of individual continuation PMCs, not directly accessible from the interpreter struct, so these won't be part of the root set.


Unless... hey!  You just gave me an idea.  I'll make a mark_regstack
that anything that holds on to one of these has to call as part of its
mark routine.

Yep, at least from the vtable->mark() of the Continuation PMC. I see there's already a mark_stack() being called there (its impl. is in src/method_util.c). That's the right spot--I should have thought of that before.


I know, it seems like a no-brainer. Mustn't have had a brain earlier :-)

Apparently, I didn't either! It must be going around.


JEff



Reply via email to