Dear Torsten,

On Tue, Jun 30, 2009 at 2:32 PM, Torsten Anders <
[email protected]> wrote:

> Dear Raphael,
> Thanks for your quick reply.
>
> First I would like to clarify that I do not propose removing any existing
> definition (they have their applications as I mentioned before, and removing
> them might also break exiting code). Instead, I only suggest *adding two new
> procedure* that are alternatives to Module.link/Module.apply.
>
> Having a permanent module manager has a non-negligible drawback: all linked
> modules remain in memory forever.  This is not good as a "default"
> behavior.  That's why in my opinion, we should stick with the current
> solution.
>
>
> I don't understand. Also with the current definition of Module.link already
> linked functors do not disappear if you link any new functors (luckily :),
> they remain in memory only they are scattered across multiple module
> managers. On the contrary, if with with the current definition of
> Module.link you link the same functor multiple times then this results in
> multiple module copies.
>

When you call {Module.link URLs}, a module manager is created.  That module
manager may be garbage collected as soon as all functors required (directly
or indirectly) by the list URLs have been linked.  So it remains in memory
as long as it is necessary for resolving module dependencies.  Once this is
done, it is no longer referred to.

As a consequence, the modules returned by Module.link can also be garbage
collected if they are no longer used by the application.  Some modules may
be linked for starting up the application, then they are automatically freed
from memory once they are not used anymore.

This happens all the time when you use the OPI, if you reload a module with
Module.link without having stopped the emulator.  The former loaded module
becomes out of lexical scope, and may be garbage collected.

Also, please note that the two new Link2/Apply2 procedures would behave
> basically like the linking between functors already does, which also uses
> only a single module manager, even if the same functor is imported by
> multiple other functors. Why should something that is good between compiled
> functors be problematic when linking functors in the OPI?
>
> Best
> Torsten
>

Cheers,
Raph
_________________________________________________________________________________
mozart-users mailing list                               
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users

Reply via email to