Or, rather, the const_string function.
Simple thing, looks like:
STRING *foo = const_string(interpreter, c-style string constant);
Easy, right? Yeah. Easy. What it does is create a new parrot string, set to the constant C string you pass in. Handy. Even marks the string as constant and external, and reuses the string constant data for the body of the string. (So there's no actual data copying for the string)
All this is cool, but... parrot doesn't garbage collect constant strings. Nor does const_string do any sort of constant string pooling, so if you call, say, const_string multiple times:
foo = const_string(interpreter, "a");
foo = const_string(interpreter, "a");you've just leaked string headers. Two of 'em. (Woohoo!) Which, if you were looking to get a string which is a real parrot constant, shared across, well, everything... you didn't get one.
Not that const_string isn't useful -- it is, very much so. Just in a limited set of circumstances, such as building the string constant table.
I believe Leo came up with a partial solution at one point, though it looks like it may not be generally applicable, and we could do some hash lookups in the constant string creation, though I'm not sure we'd want to pay that cost for each constant string. (But, then, maybe we would, I dunno)
As a partial workaround, I've added a string_from_const_cstring function, which is much like the string_from_cstring function, only it assumes you pass in a persistent, non-moving string, so it does the "I set my buffer pointer to your contents, woohoo!" thing to skip the copying step. It does *not* mark the resulting string as constant, so if you twiddle it then the string'll do the COW thing as it ought.
The patch'll get checked in as soon as its done being tested and I sync up with any collisions with what Leo's been doing today.
(This note brought to you by the letter pi, the number e, and the ten hours I burned today trying to figure out why my reports were chewing up massive amounts of memory as they ran, but showed no PMC or buffer leakage in the GC stats. Parrot was leaking one string header per bytecode vtable method call. That adds up after a while...)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
