This will be vague and handwavy, but I *think* it suggests something
that hasn't been tried before...
1. The problem of infant mortality is that resource allocation can
trigger a DOD run could wipe out the very thing we were allocating
memory for.
2. This can be solved by extending the rootset to include the 'baby'
things that we're working on.
3. But scanning the C stack is tricky, and there's also the problem of
scanning registers to deal with.
So, consider the function:
alloc_and_link( void ** handle, size_t size);
The idea is that, as part of the allocation process you also set the
link to it so, if the thing that we're pointing at our newly allocated
block of memory is connected back to the rootset then said newly
allocated block can't be reaped.
Now define the rootset as:
1. The parrot register set
2. The tops of the appropriate parrot stacks
3. A set of one or more (possibly typed) 'scratch' handles for
hanging temporaries off.
Now, all our functions which create PMCs and the like will take an
extra argument -- a handle to hang the created object off and, if
that's null, then they are free to use the appropriate scratch
handle.
opcode functions (and probably only opcode functions) can then do
(pseudocode):
op_foo (IN reg_in, OUT reg_out)
new_pmc = make_a_pmc_with_register( reg_in, the_pmc_scratch_handle)
reg_out = new_pmc or UNDEF
the_pmc_scratch_handle = NULL
Note that NULLing the scratch handles could potentially be moved out
into the main oploop, making life easier for the programmer.
>From my (admittedly handwaving) perspective, limiting the rootset to a
fixed list of things would seem to be a good idea. The question
is whether the cost of adding the extra target parameters to
everything is worth paying.
In a weird way, this can be thought of as a 'caller saves' approach to
allocation...
