Ticket #828 (closed RFC: done)
Separate out GC String Core
Reported by: | whiteknight | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GC | Version: | 1.3.0 |
Severity: | medium | Keywords: | GC |
Cc: | Language: | ||
Patch status: | Platform: |
Description
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.