On Monday 11 March 2002 20:25, Anthony Hannan wrote:
> Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
> > [compatibility problems]
>
> I guess your talking about being able to look at an object like a
> method without installing it. 

No - I was thinking about installing incompatible versions of an object 
at the same time and have one application use one version and a second 
application another.

> I didn't elaborate on this but I was
> thinking we could look at layers outside of the current image just by
> looking at their image segments and interpreting them on the fly
> without installing them.  But maybe it would be better to actually
> load these objects but not link them to the current image.  This
> would require using special "image dispatching" pointers (proxies) in
> modified fields that return the appropriate value based on which
> image is currently active.  I was hoping to avoid this for
> performance reasons but maybe its worth it so multiple images can be
> loaded simulataneously, even allowing processes to run under
> different images at the same time, and allow a process to switch
> images/perspectives quickly.  Would you guys like this better?

Not multiple images - multiple contexts in a single image.

> > [layer in a list doubles as "viewpoint" in Us]
>
> The PIE scheme makes contexts responsible for ordering layers
> correctly so dependent layers are loaded after the layers they depend
> on (parents).  Since this parent information is in the layers
> already, I like reusing that for determining load order.  We are free
> to add other independent layers to the parents list if we want to
> load others layers before it.  True if we want to reuse a layer but
> not load the same parents we have to copy it, but I think this would
> be rare, plus reusing a layer under different circumstances is more
> sophisticated/complex a concept than just copying and adapting. 
> Also, having a single layers concept is simpler than having two
> concepts, layers and contexts.

In the program developer example in the Us paper they had to copy the 
layers so both orders could be tried. In PIE this wouldn't be 
necessary. But you might be right - a layer is created in the context 
of what layers come after it (or beneath it, or whatever) and in 
general it doesn't make much sense to try to combine it with very 
different layers.

I'll have to think about it some more.

> > I have found a neat way to implement layers and contexts so they
> > can be used dynamically, but unfortunately it requires a Jitter and
> > won't work on an interpreter.
>
> I would be interested in hearing about your implementation design
> even if it requires Jitter.  This would help justify using "image
> dispatching" pointers described above.

The key technology is "selective customization" which isn't implemented 
in either Jitter or the Self compilers (but isn't too hard to add).

Customization means compiling more than one native code for each 
bytecode method. In particular, we can compile each <class,method> 
separately (note that we are talking about a "method" object here, not 
"selector"!!). This is "full customization" and is a waste of memory 
and cycles since many <*,method> combinations will have exactly the 
same native code. So selective customization would detect this 
duplication and make all these different classes share the same native 
code.

Now imagine that we customize based on <class,method,viewpoint>. As 
before, most <class,method,*> combinations or even <*,method,*> 
combinations would generate the exact same native code and so a good 
implementation would save time and memory by making them share. But in 
some cases the exact same bytecode in <class,method> would be 
translated one way for viewpoint1 and in a very different way for 
viewpoint2.

As for the actual data structures, imagine that Class1 defines instance 
variables "a b c" in layer1, "d e" in layer2 and "c e f" in layer3. We 
have context1 as (layer2,layer1) and context2 as (layer3,layer1). A 
Class1 instance is stored as three separate pieces in different files:

  layer1 - ivar1 = "a", ivar2 = "b", ivar3 = "c"
  layer2 - ivar1 = "d", ivar2 = "e"
  layer3 - ivar1 = "c", ivar2 = "e", ivar3 = "f"

The bytecodes in each of these layers reflect these mappings. When the 
three layers are loaded into memory, the pieces are combined into a 
single composite object:

   context1.ivar1 = context2.ivar1 = layer1.ivar1   "a"
   context1.ivar2 = context2.ivar2 = layer1.ivar2   "b"
   context1.ivar3 = layer1.ivar3  "c"
   context1.ivar4 = layer2.ivar1  "d"
   context1.ivar5 = layer2.ivar2  "e"
   context2.ivar3 = layer3.ivar1  "c"
   context2.ivar4 = layer3.ivar2  "e"
   context2.ivar5 = layer3.ivar3  "f"

So the final object is eight words long, though each context can only 
access 5 of those words. Native code that only uses "a" and "b" can be 
shared between the two contexts, but code using "c" has to be compiled 
separately.

There is a lot of overhead in this scheme, but it would only matter for 
an interpreter.

-- Jecel