"own" and exceptions
====================

We need to free all "own" objects when an exception happens in a thread,
and the exception does not terminate the whole process.

1. Need to know which function to call to free the object

2. Want to be able to tie "own" references to arenas, and get similar functionality

3. Want to have reasonably good performance in the non-exceptional case.

(this is probably why garbage collection and exceptions are often combined,
it is simply easier to do exceptions with garbage collection)


Solution
--------
There are actually two types of "own" allocations:
1. Allocations "without" an arena (or in the "main" arena,
   but that is an implementation detail)
2. Allocations that are tied to an arena.

When "own" allocations are tied to an arena, they are allocated in a
"malloc/free"-allocator zone of the arena. They can also be free'd.

Otherwise, they are allocated in some kind of "main" "main/free"-allocator
zone.


The base arena block is extended with a pointer:
- pointer to malloc/free allocator zone header (may be NULL)

The allocator zone header might contain some kind of free lists or similar.
(The header itself may be allocated in the arena).

When malloc-allocations are free'd, the arena information will always be
available.
- So there is no need to have next/prev pointers before/after the allocated
  block. Instead, there could be an index or similar in some kind of "alloc
  list".

The allocation header and information:
- It could have power-of-two sizes for free lists. Allocating a non-pow2
  size gives some free space at the end. If more than 8 bytes, then we can
  put it in the free list for that size
    - Except when the next item is free. In that case, the following
      addresses may either be all free, or some allocated data may follow.
      How to handle the latter case?

When an exception happens
-------------------------
We need to figure out which arena(s) are active!

Possible solutions:
1. A thread local pointer to the active arenas
2. A constant lookup table from code addresses to lists of registers / stack
   entries that references *active* arenas.
   - Problem 1: Saved values of callee-saved registers may exist in an
     unkown location if a function is called.
   - Problem 2: The stack needs to be traversed.
   - Problem 3: Arenas can be free'd. Need to process only active arenas.
3. A lookup table that maps threads/tasks to arenas. (Has to be accessed
   in a thread safe way)


Solution 1 and 3 are by far the most simple ones. Thread local storage
requires an additional register on many platforms.
-> Number 3 is probably the best one, unless we can be sure that we
   have thread-local storage (and can sacrifize the register)