Mike Lambert wrote: > I'm currently favoring allowing for header pools on a per-type basis, not > just a per-size basis. This would give us a 'hash' pool. The pool > structure would contain function pointers for collection and/or dod > purposes. (stuff that would otherwise be in a PMC vtable.) 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. > > > 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.
> 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. > > a) no pmc type morphing. once in a pool, it stays in a pool. I don't see > this as a big loss, since type morphing is error-prone to begin with, imo. The main issue here would be the definition of pmc type, in an untyped language. We may need a PerlScalar pmc type, as that is what most Perl variables really are - if we stick to using pmc types based on current content, then we need to be able to morph between the different subclasses of PerlScalar as the contents change. > > b) data members! Since not all pmcs are the same size, pmcs are able to > store data elements in their structure. This allows us to make a SV-like > PMC which stores str-value, int-value, float-value, etc. All without Okay, you were obviously thinking the same way! > > Thoughts on all of the above? The main drawback that I see is that we can > have a lot more pools. Currently, we don't take advantage of sized header > pools, so making them per-type won't hurt us. However, by making different > pools for different pmc types, an explosion in base pmc types could cause > an explosion in pools and create wasteful memory usage as each pool stores > 'extra' headers for allocation. This can probably be tuned in some form > to reduce over-allocation's affect, but I thought it wise to bring it up. 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. > > 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! -- Peter Gibbs EmKel Systems
