Discussion: #MutableConfigurations

[Alan Bateman]

I don't wish to interfere in this discussion but just a few points:

On 13/07/2016 21:58, Paul Benedict wrote:
> Analyzing and resolving memory leaks is not my expertise, but I have done
> it occasionally. Correct me if wrong, but if a Layer has to be rebuilt at
> runtime when one module updates, doesn't that create a large graph of
> objects in need of garbage collection? And doesn't that also put EE servers
> in the danger of having ill-referenced old Layers that gobble up memory?
> Given such a theoretical JEE 9 server which users Layers and Modules, I
> would suppose rebuilding the Layer (instantiating new) means rebuilding
> each Module and in turn each Class? I remember Mark Thomas (of Apache
> Tomcat) once writing to Jigsaw-Dev@ on the topic of memory leaks [1]. I'm
> not claiming my question/concern here is identical to his, but it might be
> related.
There are stress tests in the JDK 9 forest to exercise this. Clearly 
someone could keep a reference to a Module or its ClassLoader that keeps 
an entire graph of objects alive but that is no different to other cases.

The proposed module system was never meant to be a dynamic module system 
where modules in a graph of modules (module layer) could be GC'ed and 
re-instantiated individually. That's a different design.

>
> Regarding hot deploy, I am familiar with classes being recompiled and
> replaced in memory. But I don't think that's what David is driving at. So
> what does it mean for module-info.java? If I change any "export" or
> "require" statements in a live debugging session, is the answer do full
> rebuild and redeploy? I think this similar is what David is driving at.
>
If you are familiar with redefineClasses then you will know its 
limitations too. There isn't any support in the platform for arbitrary 
schema changes. There are frameworks and EE servers that work around 
that of course but that's a big other topic.

If you are changing a module declaration then you will typically create 
a new configuration (resolution, post-resolution checks) and then 
instantiate it as a new layer. There is support for tool agents to 
change modules in the runtime, this is limited to expanding the set of 
exports, expanding the set of modules that it reads, or expanding the 
set of services that it uses or provider. It may be possible for 
debuggers to leverage this for some limited cases but it not arbitrary 
changing a module.

-Alan