Hey Peter, (Well, it's directed at Peter more than anyone else, but others are allowed to chime in. ;)
Have you given any more thought to submitting your COW patch? Dan and I talked a bit about this on IRC, and came up with a few ideas. The data which needs to be stored along with the buffer data, can be stored as either a header or a footer. The size of this header needs to be a multiple of 16 (or possibly even 8) bytes, so that the real buffer which follows would be correctly aligned. I'm not sure if this applies for a footer. One of Dan's gripes was that doing this makes buffers less lightweight, and not as freely used. A footer might allow us to to tack 5-8 bytes on to the end of an allocation, which might not always go 'over' the 16 byte rounding-up limit we currently have in place. As long as we're not just-below the 16 byte barrier on most of our allocations, this shouldn't waste any more memory. Alternately, we could introduce a flag into the buffer header, which indicates whether or not the associated buffer is COW-able, and if it is okay to look for the header/footer information. This would allow us to only turn on COW for strings, and leave it off for buffers in general. This flag would be immutable over the lifetime of the buffer header, and it would need to be copied into any COW buffers as well. This flag would also necessary to determine how much memory to copy in a collection run. This latter approach might introduce too much overhead and brancing into the GC system, however. Thoughts or preferences? Mike Lambert
