Peter Gibbs wrote: > I am very much in agreement with this concept in principle. I would like you > to consider adding a name/tag/id field to all pool headers, containing a > short text description of the pool, for debugging purposes.
I don't have a problem with that. And yes, it'd definitely help debugging (as opposed to printing out the various pool addresses and comparing them ;) > > One idea, which is most closely in line with the current semantics, is to > > add a pool pointer to every header. I've found a few times in the past > > where such a pointer would have come in handy. This would allow us to call > > the pool's mark() function, to handle stuff like pointing-to-buffers, etc. > This is something I have done in my personal version, for buffer headers > only at present (I have been mainly ignoring PMCs, as I believe they are > still immature). I use it for my latest version COW code, as well as to > allow buffer headers to be returned to the correct pool when they are > detected as free in code that is not resource-pool driven. Re: DOD immaturity: Yeah, I agree to some extent. It's somewhat difficult to test DOD efficiency because every string is directly traceable from the root, thus avoding mark_used for the most part. Perhaps some GC-PMC benchmarks are needed to weed out remaining issues. Re: COW code. Ooohh! You've kept it up date with the current code? I was working on applying your old patch (ticket 607 at http://bugs6.perl.org/rt2/Ticket/Display.html?id=607), but if you've gow COW code in the current build, that's even better. One question: does your current code utilize bufstart as the beginning of the buffer, or the beginning of the string? > > b) it allows us to make new types of buffer-like headers on par with > > existing structures. > On this subject, I would like to see the string structure changed to include > a buffer header structure, rather than duplicating the fields. This would > mean a lot of changes (e.g. all s->bufstart to s->buffer.bufstart), but > would be safer and more consistant. Of course, strings may not even > warrant existence outside of a generic String pmc any more. Again, I agree. If the COW code forces all the string usage to use strstart and strlen, then bufstart and buflen essentially are used a *lot* less. This should make the mental transition easier. > One option would be to use a limited set of physical sizes (only multiples > of 16 bytes or something) and have free lists per physical size, rather than > per individual pool. This would waste some space in each header, but may > be more efficient overall. I suppose this allows us to mix and match entries of different types in same pools, since each header would have a pointer to its own pool, regardless of its neighbors. However, the number 16 could be tuned to 4 or 1 to achieve slightly better mem usage. (Or even POINTER_ALIGNMENT). > > Finally....the unification of buffers and PMCs means that buffers can now > > point to things of their own accord, without requiring that they be > > surrounded by an accompanying PMC type. > How about the other way round? If the one-size-fits-all PMCs were to be > replaced by custom structures, then everything could be a PMC, and > buffer headers as a separate resource could just disappear! I think you misunderstood me here. I agree that making the buffer headers a distinct resource is unnecessary. However, this does mean that all headers need to be traced now. For pure strings, this can hurt performance, although one can argue that it helps performance in the general case of the PMC containing buffer data (a couple less indirections needed on usage). We could make a new header flag, BUFFER_has_pointers_FLAG, which specifies that this buffer contains pointers to other data structures, and should be traced. If this is unset, the buffer doesn't get added onto the free list. Since adding it to the free list requires adjusting next_for_GC, it's already going to reference memory there. Checking the flag would merely prevent traversing the memory again in the 'process' portion. Thanks for the quick reply, Mike Lambert
