LLL: Control structures and code caching

[Francois-Rene Rideau]

>       First, how are we planning to represent control structures?  Will 
> our language support such primitives as if/while, or will it have only 
> conditional jumps?  How low-level is our LLL anyway?
   Excellent question. I'm not sure about the answer. Maybe we should
test both possibilities...

>       Second, it seems to me that Tunes should be able to execute code 
> larger than physical memory, perhaps 20 times larger if necesary.  (I'd 
> like to put the code size limit as the size of the disks.)  This will 
> require support from some not-so-standard VM techniqures.
   I almost agree. Well, almost: don't plan to support a flat memory model
(like on large distributed shared memory computers), but an object-oriented
model. Which means there is no a one large but fixed-size encoding for
pointers, with pointer arithmetics, and page-wise security checking, used
everywhere in the system; rather, there is computing freedom: a program uses
local pointers of the size it would, but objects communicate if they share
the same protocol, whatever size it uses for pointers, and even if it has no
pointer arithmetics.


>       I suggest we support paging, but not the standard means of 
> swapping.
   I completely agree, but methinks swapping cannot be avoided completely if
we mean performance: it's the fastest way to save data, without having to
reencode and redecode it (which may be slow to do). So temporary objects
may like to be just swapped.
   Actually, I'd recommend having an object-parametrizable policy, so
some objects would be saved and compressed, just partly or completely
forgotten (the forgotten part being recomputed on demand), or swapped
exactly, or whatever.
   The main problem, as always, is with references: how will we recode
pointers consistently so that the save is ok, and (if possible) we won't
have to update its value when a garbage collection runs ?
   Actually, the problem of swapping out objects is much alike migrating
to a memory-richer, but cpu-poorer :) system. Perhaps we can have the
same object manage both. Recoding the objects seem much alike problems,
but if the data is to be restored on the same host (i.e. pure swapping),
then recoding may not be necessary...
   Now, if a small part of a big compressed object is modified, there's a
problem, so we need have a way to schedule those (objects are to be annotated
according to their mutability as wel as there communicability and
cpu-intensity).


>       Yet another problem extends from the fact that LLL operations must 
> be fairly atomic, since the instruction counter is kept on the basis of 
> LLL code.  (How else might we migrate processes to different 
> architectures?)  I suppose it wouldn't be too hard to let a process 
> finish its current LLL instruction before it is migrated, but telling how 
> much you have left to go from the PC might be sorta' difficult....
   That's exactly why I proposed a cooperative scheme for garbage collection
and migration, while real-time threads would be unable to use GC-able memory
or network communication (though they would be able to queue requests for such
accesses, and a standard library would help them do all such things).

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
MOOSE project member. OSL developer.                      |   |   /
Dreams about The Universal (Distributed) Database.       --- --- //
Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
Phone: 033 1 42026735                                    /|\ /|\ /