> The one problem with copy-on-write is that, if we implement it in
software,
> we end up paying the price to check it on every string write. (No free
> depending on the hardware, alas)
>
> Not that this should shoot down the idea of COW strings, but it is a cost
> that needs considering. (I suppose we could have a COW subtype of the
basic
> scalar and string scalar)
Even with software implementation, it can come almost free. In this case,
I can use two sizes for each string, readSize and writeSize. The write
operation will check agains writeSize as part of normal bounds check.
If an string is read only, (such as literal), the writeSize will be 0, and
we
do copy on write. The same scheme applies to string growth. So the price
is just one extra word (writeSize) per string. Since this enables us intern
all literal strings without introducing another data type, I would say the
overhead is minimal.
Hong
