RegExpCache may hold on to too much memory for three reasons: (1) Caching 256 RegExps might be too man, for some platforms. (2) The RegExpCache gives regular expressions a very different lifetime to JIT translations of JS code, but they share an ExecutableAllocator, and thus share ExecutablePools. This means the RegExpCache may end up keeping the JIT code for translations of JS code alive. (3) Regular expressions in the RegExpCache may be sharing ExecutablePools. If this is the case, rejecting a single RegExp object won't actually free up any memory. This means the cache holds onto complied regular expressions that it cannot vend.
Patch landed in r74441 addresses the first two issues, but the third concern still needs to be addressed. The best resolution to this may be to remove the pooling of executable code, allow individual, arbitrary sized allocations.
http://trac.webkit.org/changeset/74441 might have broken GTK Linux 64-bit Debug