LLL & Migration

[Nathan Hawkins]

On Sun, 14 Apr 1996, Francois-Rene Rideau wrote:

> Dear LLLers,
>    the current design is that by cooperating,
> threads can enforce lots of information
> to be consistent at thread-switch points,
> thus allowing GC, and Migration in general.

I'm starting to think we need to do both.

>    NOW, as for Migration, I previously intended
> to make swapping a particular case for it;
> but just realized how if we rely on hardware paging,
> swapping, and thus some kind of Migration, could be required
> at just any place in a program !
>    Hence, unless we find and adopt some nifty trick
> so that there is always a safe point between the time swapping is
> scheduled and the time its completion is required,
> there will be a category of Migration thingies that
> should not rely on any software consistency conditions.
> 
>    Communication, authentification, and arbitration protocols
> that can be used for low-level Migration
> thus mustn't rely on the common GC'ed heap,
> and should use separately allocated memory.
> These include auto(de)compressors, net swappers,
> and all the according scheduling code:
>    like any interrupt-driven "real-time" code,
> none of these can't directly access common GCable data,
> because it may be inconsistent at that time,
> so they should be mostly "dumb" things.

How common should a heap be? Maybe we need to emphasize multiple heaps, and 
then work out some way to make cross-heap access safe. Maybe we could 
require indirection through a pointer the GC knows about, which would 
allow the GC to automatically update cross-heap pointers, but only 
GC one heap at a time. Then, allow threads to be pre-empted, but only by 
a thread running in another heap. Thus, threads from the same heap, would 
be cooperative, but the preemptive multitasking between heaps would hide 
time spent doing GC from the end user. :-)

At the page level, the swapper will probably have to be written to 
ignore the consistancy of the page. Otherwise, we'd have to deal with the 
issues you mentioned. A question: how important is this for local 
storage/VM? I would think even persistancy could be acheived at the page 
level, but not for small objects, naturally. Which brings up the question 
of whether that is important. Do small objects within a heap need to 
persist separately from the heap?

It would be very easy to say that for heap X, all we do is store the 
heap and stack. A bigger problem is getting the address space to do it. 
So, I would suggest that for 32-bit chips, we should use multiple spaces 
and require that higher level access methods be used than pointers. This 
is overhead, but would probably help us, since most migration code could 
be written and debugged entirely on a single machine. (Migration of 
threads between address spaces could be very similar to migrating to a 
different machine.)

> However, some "normal" threads could very well
> send information to and control the real-time ones,
> to make them less dumb.
> But the interrupt-driven things must be able to run
> even without this feedback.

Right. Those will need very special handling, and they'll require 
special code to access them safely. We'd need semaphores, at a minimum. 
Probably should completely protect real-time threads in a special heap or 
two. Then, use a fairly conventional low-level interface for the lowest 
level access. This should protect the interrupt driven threads from being 
broken by external code, or from trying to use something external at a 
bad time. This could be done entirely in software, but using the paging 
hardware would be justifiable here, since that would be for the purpose 
of enforcing software constraints.

*utsl*