Fare's dynamic linking

Mike Prince mprince@crl.com
Fri, 23 Dec 1994 19:28:35 -0800 (PST)


On Fri, 23 Dec 1994, Francois-Rene Rideau wrote:
> ### How dynamic linking works ###
>    So, when an object really needs evaluate another, the call just gets inlined
> then executed; but to allow migration, we need that source code be remembered,
> and that at migrationable points, object state be uncompilable.

How do you uncompile, how long will it take, how do you know where a 
migratable point is, how big is the source code vs binary?

>    Here is an example (I hope you'll be satisfied, Mike):
>    Imagine that modifying an array A was inlined to a direct memory access.
> Then, you can still migrate the array (if it is heavily needed somewhere
> else), or even part of it (if the large array was properly segmented to allow
> it, which can very well be compatible with inlining accesses). But then,
> direct memory accesses will be invalidated,

How do you keep track of who uses what?  For instance, is there a module 
that keeps a list of all data and who references it?  What is the 
granularity if so (integers, groups of data, all module data)?  If some 
data moves, do you have to recompile all the modules that access it?

How do you segment an array?  Does my software segment or the OS/compiler?

If you moved a data object that is used by everyone, does that mean the 
entire system would re-compile?  (say a crucial kernel-like module changed)

>    Note that all this {,un,re}inlining stuff is costly enough so that
> real-time threads should avoid them by locking all necessary resources.

Who manages the locking/unlocking?  (I know it's a module under your 
scheme)  But how does it work?  Assembly pseudo-code would be great to 
demonstrate your ideas!

>    As for RPC, we'll eventually provide a large span of RPC managers,

I'm totally against RPC's.  The call to a module should appear the same 
whether it's on the same machine or a distant one.  If you're talking 
about a module using RPC's as a way of accomplishing this "transparent" 
service then thats going in the face of us developing a standard 
messaging format for agents and cells.  You're making this too 
complicated, supporting too many standards, and locking yourself out of 
using certain facilities if you use RPC's.  Drop that idea and accept 
threads flowing from one machine to another.

I guess what I'd like to see is some pseudo-code showing us how all this 
would be done.

Mike