id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	lang	patch	platform
828	Separate out GC String Core	whiteknight		"Parrot really has two separate GC mechanisms: the fixed-size pool allocators (like GC_MS) and the string allocator.The string allocator does all sorts of fancy stuff like memory compacting, but it relies pretty heavily on encapsulation-breaking knowledge of the internals of the GC_MS.

In this ticket I propose two things:
1) We be more clear in our documentation and PDDs that we really have two separate cores that do two separate things
2) Improve the interface to the string allocator (and maybe modify the existing GC interface) so that the string core does not depend on intimate knowledge of the workings of the fixed-size core

The alternative is that we combine the two and be more clear that any new gc ""core"" will need to implement handler functions for both fixed-size headers and arbitrary-sized string buffers. This will require a little bit of rearranging the current GC to put string mangement functions into the GC_MS file."	RFC	closed	normal		GC	1.3.0	medium	done	GC