Memory model for the LLL

[Francois-Rene Rideau]

>> For instance, will we allow pointer arithmetics ? (I hope not)
> Yes, CPU's do it, why can't the LLL.  Remember, a HLL can always not use 
> this feature!  Pointers are within segments for process protection.

I'm not so sure. Of course, pointer arithmetics will ultimately be used
on computers with a linear memory model. But we may hide it.
Why ? 'cause it may imply too high costs for our implementations (i.e.
having infix pointers), without bringing anything that some local
optimization on LLL code wouldn't bring.


>> Will we allow infix pointers (not pointing to the beginning of an
>> object) ?
> If the LLL has to deal with objects as such, it might become too 
> dependent on one way of "thinking", I'm going for a general memory 
> allocation strategy and let the LLL program determine it's use of the 
> storage (i.e. one "object" per memory allocation, an array of them, a 
> stack of them, etc).
  The problem is garbage collection. Any system needs some garbage collection
mechanism, particularly a persistent system.
Unix uses huge grain for persistence (=files), and a system call for any
operation, so keeping counters become negligible in front of such overhead.
But we want any grain of objects, including small grain; thus system call,
counters and owner lists are some big overhead (we don't wanna the LLL to
do a system call at each instruction manipulating a pointer); we need some
blazing fast LLL, and memory model is important.
   Once it allocated some raw zone of memory, a program might do anything
with it. But GC means we need trace down pointers; and this is *very*
important. Storing a pointer into an integer can never bring anything good
to the system, but can crash it.


>> * Any implementation would use native pointers as values,
>> with lower or higher bit(s) to indicate the value being pointer
>> or integer, thus losing one bit. For ;ore portability, integers
>> would come with size 8, 16, 32, or 64, even though the architecture
>> be 20 bit.
> 
> I thought about this before, but it sounds like a huge performance hit 
> for the LLL.
The other solution is separating pointers from integers, which also
means separating integer registers/stacks from  pointer register/stacks.
This may be ok on machines with a lot of registers to waste, but not on
the i386. Of course, this old stupid architecture shouldn't limit us.
But having multiple separated stacks also means some non-negligible
memory management overhead, plus a bunch of different LLL instruction to
deal with these. I'm not saying it's not worth it, but that I don't
currently feel it is.


>> * Pointers would never be infix (except in transient state);
> 
> Transient state?  You mean migration or message passing?
I mean during times when no GC is possible; which means while
interrupts are disabled if using preemptive multitasking, or
between two PAUSEs (not more) if using cooperative multitasking
(I'd rather we use the later, at least as of native programs).


>> * GC would happen only during cooperative multithreading, while
>> preemptive multithreading is allowed for real-time behavior on
>> preallocated (outside global GC) zones.
>
> GC would happen when the kernel/memory manager object says it would
> happen.  It is not dependent on the state of any threading.
Yes it is. Many operations need to be atomic as regards the GC, so you
must disable all interruptions, or be sure no GC will take place during
them.


>> * objects with size different than pointer size are allocated on
>> heap.
> All memory is allocated from the heap.
Yes, but I meant that if you're using a 31 bit integers on a stack
implemented with 16 bit words, it'll be allocated on heap. We'll not
maintain implicit double-cell values, because that would prevent
migratability (of course, if double cells for 16 bit values were
explicitly asked for, that's another problem).

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