Problematics of object memory modularization (Was: Re: [squeak-dev] binary development (was: 3.11 and the trunk))

>>
>>
>> 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.
>>