As already outlined the current copying GC isn't really thread-safe. A
possible solution is to suspend all threads, while the shared
interpreter is running garbage collection.

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