Michael L Maraist wrote: > Are we allowing _any_ dynamic memory to be non-GC-managed?
Parrot must allow third party libraries to use the standard system malloc/free. Playing linker games to hide malloc/free gets *really* ugly. > Can we assume that a "buffer object" is ONLY accessible by a single > reverse-path-to-PMC? IMHO whatever we want to call private shouldn't be accessible to extensions. If singleton buffers make GC easier then do it. PMC internals are definitely private -- vtables require it. > I believe Dan said that we _could_ assume that PMC's were unmovable The term PMC is used in two ways: a PMC is an opaque handle to a Perl variable, and a PMC is a struct that holds (meta)data for a Perl variable. The handles are movable, but the structs aren't. This isn't a big deal since the structs are all the same size -- it's the array of handles concept often used to simplify GC. I don't think anybody has decided whether PMCs nested inside another PMC (arrays/hashes) follow the normal PMC rules. (It would be a pain to use them if they didn't, but there are lots of optimizations that need contiguous+movable internals.) > Are _all_ handles (PMC's, Strings, or whatever) that serve as > root-set elements dynamically allocated? Nope. Part of the root set includes auto C PMC handles used by extensions. You also have to think about hardware registers too if GC is running in another thread. IMHO the easiest way to code this is to define an API that extension writers use to declare every PMC handle. This code looks ugly and encourages bugs though so a lot of people don't like it. Many systems treat the C stack as conservative roots. Those systems flush the hardware registers to the C stack before running the collector. The benefit is that handles don't need to be declared. The cost is the non-portable code used to scan the C stack and flush the registers. Another simple solution is to suspend the collector while in extension code (or untrusted extension code). This works for lots of cases, but falls apart badly in callback/event-loop extensions that never return. One nice thing about writing Perl extensions is that the "SV *" can be stuck in odd places. For example, I put them in X Toolkit and Motif widget "user data" slots. Once the "SV *" are stuck in the slots I have no idea what happens to them. This works fine because the ref count will keep the SV alive until the widget dies. A hybrid ref count GC with pinned PMCs will work exactly the same. If we get fancier though and either use movable PMCs or tracing collectors, then my "user data" slots become roots. That will crash and burn because I don't know how to register them. I'd have to use a separate array for holding the PMCs and then stick the array indexes into the widgets. It's probably not worth making my job as an extension writer easier if it slows/complicates the rest of the GC. Most extension writers are pretty good at this sort of thing and a special utility library for pseudo-pinned PMCs wouldn't be any big deal. Hmm. I guess that argues against pinned PMCs. Maybe the best thing is to develop a public API to PMCs that doesn't assume pinning. That way you can use pinned PMCs as an implementation optimization while leaving the door open for changing the internals in the future. Other extension writers may have a different view. ;) Asking for comments on comp.lang.perl.modules would be a good idea. Maybe the perl-xs mailing list too. - Ken
