A shared-all thread type could use the same scheme, instead of explicitely declare a PMC to be shared, all is shared implicitely and is living in the shared interpreters arena_base.
OTOH the copying collector has disadvantages for the unthreaded case too (e.g. hash buckets can get moved during string_compare). We already have a non-moving GC system selectable at configure time. But when the external LEA allocator is used, memory allocation isn't thread safe. Libc's allocator is based on ptmalloc[1] - an early offspring of the LEA allocator, but ptmalloc isn't portable.
We can use the underlaying C-library as our allocator, but there are AFAIK speed issues on some systems.
And finally: Recent issues with fedora and non-executable JIT code also show a demand for an allocator inside parrot.
Writing a full-fledged allocator isn't trivial. Following the glossary and bibliography links from e.g. [2] may keep you reading for a while :)
Having an own allocator would have another advantage: We can pass hints to the allocator about the usage of the memory block. Executable code for JIT is long-living and unlikely to be resized. String buffers used e.g. in string_append, freeze, or Parrot_sprintf are very likely of having a short life-time and being subject to resizing.
leo
[1] http://www.malloc.de [2] http://www.memorymanagement.org
