On Thursday 22 November 2007 20:33:19 Mark Glines wrote:
> > There is a memory leak with the STRING's. Next C code consumes more
> > and more memory, but does not free it:
> >
> > for(i=0;i<20000000;i++) {
> > string_from_literal(INTERP, "nothing");
> > }
> Unless I'm mistaken, string_from_literal() is an allocation function.
> The string it returns needs to be freed again, with a call to
> string_cstring_free(). I think this is true for all of the
> string_from_* functions.
You may be thinking of string_to_cstring(), which copies s->strstart out of a
Parrot STRING s into a new char *. string_from_literal() just allocates a
new STRING header s and stores a char * in s->strstart.
In theory, the resulting STRING participates fully in GC, so when it's no
longer reachable it gets reclaimed. That may not be working completely
though.
If it is working correctly, the loop will reach a high water mark of
allocations as it fills up the pool of STRING headers, but will stabilize
around that point. (I think the pool will have 10 pages / sizeof the STRING
struct headers in it.)
The memory for the literal strings doesn't come from pools, so there'll be
that overhead too.
It shouldn't eat any more memory... but if you never relinquish control to
something in Parrot that can trigger GC, you'll never see any memory reuse.
-- c
