Shared arena threads, GC, executable memory allocator
Leopold Toetsch
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