2009/8/25 Eliot Miranda <eliot.miranda at gmail.com>:
[snip]
>>
>>
>> But, if system modelled in modular layers , like kernel -> services ->
>> interfaces -> working set,  then things
>> would be much easier to handle.
>
> Yes, yes, yes!!  The system should be like an onion where each layer of the
> onion is a set of interlocking techtonic plates of modules of functionality.
>>
>>
>> > I added a bulk instancesOf primitive that answered all instances of an
>> > Array
>> > of classes that my colleague Steve Dahl wanted to use in instance
>> > migration
>> > on class redefinition.  This could be used to look for all instances of
>> > the
>> > classes defined by a parcel prior to unload.  Do a GC, collect all
>> > instaces
>> > of classes defined (rather than redefined) by a parcel and warn if
>> > non-empty
>> > (if in a dev image).
>>
>> I think that independent tiny layers (isles/vats) is the future system
>> organization in smalltalk-like VMs.
>> First, it gives the strong answer to question, what belongs to what.
>> There is no possibility to reference a foreign object
>> other than by far ref. You can count/enumerate them easily, and this
>> approach also makes possible to run code in vats concurrently.
>> The problem here is how to handle the shared behavior, like Arrays,
>> Collections etc in order to avoid duplication. Since in smalltalk
>> everything is objects, and so methods & classes too, they can belong
>> only to a single island/vat, and therefore , only owning island can
>> manipulate with it. This creates a major bottleneck in effective
>> implementation of concurrently (and independently) running the code.
>> Trade space for speed? Allow each island to have own Array class with
>> own implementation?
>> This question remains open for me.
>
> Yes, this is a cool radical idea that I haven't got my head around yet.  I
> need to think about this at length.  The obvious approach to the duplication
> is copy-on-write where any modifications to the root Array class get
> propagated to the copies, assuming there is some hierarchical control
> organization.  I think this approach is taken in Alex's worlds where
> modifications to a parent world are seen my children.  But then the merge
> problem rears its head when trying to propagate modifications to a child
> that has made its own local modifications in the same region.
>>

One big problem with anything, related to copying is violation of
object identity.
Once you violated it (by copying & creating surrogate), next you need
to invent mechanisms to
imitate the preservation of identity. And steps/measures you
describing above failing under that category.

I'm not a fan of this approach, because it doesn't trades space for
speed or speed for space,
it is a complete drawback in both areas - on each write you making a
copy -> means more space & less speed, as well as increased
implementation complexity. As to me, this is a dead end.
For same reason, i think that a popular (among people who designing a
concurrent systems) transactional memory approach doesn't fits well
with smalltalk.
So, I prefer to explore less expensive solutions, if they exist.

The second problem is actually implementation. We having a VM from one
side, but if we look at it from a smalltalk's perspective - where
everything is an object and there is no magic, so i'd prefer to not
have a magic in this case as well. I questioning myself, what model is
most powerful for VM, to let a language side to decide how to deal
with concurrency & isolated object memories which exchanging by far
refs?

>From one side, a message passing scheme alone, doesn't says anything
about how , when and in what way message will be handled. But once we
going inside this mechanism, we soon discover a can full of worms,
which you illustrated very precisely by rewriting Monty Python's in
your blog:  'Amongst our weapons… Amongst our weaponry… are such
elements as objects, po…'

For instance, first thing which pops up from the can, once we open it
- is message selector. If we passing a message to object which belongs
to foreign island, the selector should be understood by an object
otherwise we get DNU. This means that selector should also belong to
same island as object itself. Or we should have some kind of selector
translation/matching mechanism between two islands.
And see, i'm only scratching the surface :) Dead end again?

Does smalltalk's 'everything is an object' means: no any fairly
effective concurrency support implementation is possible?


-- 
Best regards,
Igor Stasenko AKA sig.