Module isolation

[Bryan Atsatt]

Stanley M. Ho wrote:
> Hi Bryan,
>
> Bryan Atsatt wrote:
>> ...
>> It seems to me that if we're going to follow this model, then:
>>
>> 1. There is a 1:1 relationship between ModuleDefinition instances and
>> Module instances.
>
> ModuleSystem is the one actually handling the module instances'
> instantiation, initialization, and release. Typically, instantiating a
> Module from a ModuleDefinition through the ModuleSystem will return the
> same cached Module instance for sharing, and it's 1:1. That said, the
> ModuleSystem also has a releaseModule() method (see Section 7.1.4 in the
> spec) that allows Module instance to be released from the cache when
> necessary, and that Module instance will be GCed eventually. If a
> ModuleDefinition is instantiated multiple times and each time
> ModuleSystem.releaseModule() is also called for that ModuleDefinition,
> it is possible to have multiple Module instances in memory for a given
> ModuleDefinition, although calling getModuleInstance() method on
> ModuleDefinition will only return the Module instance in the
> ModuleSystem's cache.

Apparently I don't understand the use case here. Though releaseModule()
is exactly like the detach() method I put in the prototype, I realized
long ago that this pattern does not work well for isolation, as you
cannot control access to the original instances *or* the subsequent
instances--there is no "transaction" model.

A separate, private, Repository instance, OTOH, does provide such a model.

Can you please explain the use case for releaseModule()?

If there is no strong case for this, I would much prefer to stick with
the very simple 1:1 model.

>
>> 2. Given #1, why does the getModuleInstance() method on ModuleDefinition
>> need to call through to the ModuleSystem? As it is, the ModuleSystem
>> must keep a separate map, which seems like overkill. The definition type
>> will be specific to the module system, so it can always instantiate the
>> correct type, and simply cache it in a field.
>
> That's because ModuleSystem does much more than instantiating a Module
> instance from a ModuleDefinition. ModuleSystem is also responsible for
> initializing the Module instance to interconnect the imported modules
> (and resolve potential cyclic dependencies) and to perform type
> consistency checking. To do module initialization properly, ModuleSystem
> needs to be aware of all the cached Module instances (so they can be
> reused for sharing) and all the Module instances that are in the process
> of instantiation, initialization, and release.

Of course ModuleSystem must be involved, but that is orthogonal to
*where* the instance is cached.

Would you agree that if we did not support releaseModule(), caching the
Module instance in the ModuleDefinition would eliminate some complexity?

>
> The getModuleInstance() method on ModuleDefinition is simply a
> convenience method to get to the Module instance from the ModuleSystem,
> and ModuleDefinition does not keep track of any Module instance itself.
> It is the ModuleSystem doing all the actual works.
>
>> 3. The ModuleDefinition copy operation and semantics must be defined. We
>> could simply implement Cloneable, or create a copy() operation. Either
>> way, it needs to be clear *what* is copied; I would think we would copy
>> all of the data *except* for the ModuleDefinitionContent.
>
> It is unclear to me which use case you have in mind that requires
> cloning of ModuleDefinition. At a high level, the information in
> ModuleDefinition can be retrieved from ModuleDefinitionContent. If you
> have a ModuleDefinitionContent instance, you could simply construct new
> ModuleDefinition instances with it, and you don't need cloning.

Isolation requires creating a separate repository instance that wraps
another, and hands out *copies* of definitions from the underlying instance.

We simply need a standard way to make such a copy, one that does not
require knowing the actual subtype.

>
> - Stanley
>