GSOC 2010 Proposal: Immutable Strings

[chromatic]

On Monday 29 March 2010 at 15:39, Tyler Curtis wrote:

> Would immutable strings be better than the current copy-on-write strings?

They're not in conflict; they complement each other.

If you perform a substring operation of an immutable string, you can create a 
new string header with the COW flag set, record a different starting and/or 
ending point for the substring, and point to the same string contents as the 
larger string.

Our current system *requires* us to create a new COW header for every place in 
the code which returns a string somewhere else, because that string may get 
modified in place out from under something that doesn't expect it.

That is to say, if you want to read the name of a class, you get a COW header 
for the class name even if you never write to the class name.  (If you *did* 
write to the class name -- because that name is immutable, because all strings 
in Parrot are mutable -- you'd modify the class's name in place and make a 
huge mess of things.)

In other words, we've made *reading* strings expensive.

A COW scheme makes *writing* strings less expensive because it delays the 
copying and modification of memory until it's absolutely necessary... at least 
if you don't have to allocate a new COW header for every string operation, 
especially reads.

-- c