LLL & Migration

[Francois-Rene Rideau]

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.

   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.
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.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"