Discussion: #MutableConfigurations

[Paul Benedict]

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.

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.

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-April/007376.html

Cheers,
Paul

On Wed, Jul 13, 2016 at 3:36 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> Yes, and that means new modules, which means new classes.
>
> On 07/13/2016 03:32 PM, Paul Benedict wrote:
>
>> Question: If Configurations aren't mutable, would that necessitate
>> rebuilding the Layer if you want a modified Configuration? And by
>> rebuilding, I mean obtaining a new Layer instance.
>>
>> Cheers,
>> Paul
>>
>> On Wed, Jul 13, 2016 at 9:30 AM, <mark.reinhold at oracle.com
>> <mailto:mark.reinhold at oracle.com>> wrote:
>>
>>     Reference:
>>
>> http://openjdk.java.net/projects/jigsaw/spec/issues/#MutableConfigurations
>>
>>     2016/3/2 18:11:34 -0800, david.lloyd at redhat.com
>>     <mailto:david.lloyd at redhat.com>:
>>
>>     > It appears from what I can see in the Jigsaw code, that once a
>>     > Configuration is calculated, it cannot be changed in any way,
>>
>>     That's true.
>>
>>     The overall model in the present design is that, given a set of
>> modules,
>>     you first compute a configuration, which captures the resolution of
>> all
>>     the modules' dependences in a consistent fashion.  You then
>> instantiate
>>     that as a Layer (or even more than one Layer, if you want).
>>
>>     This model is motivated by one of our primary goals, namely reliable
>>     configuration.  Resolving a complete configuration, rather than doing
>>     so incrementally, allows the early detection of missing, duplicate,
>>     and conflicting dependencies.
>>
>>     >                                                               which
>>     > makes them unsuitable for use in containers which add and remove
>> modules
>>     > at run time.  It is not clear how such containers are expected to
>>     > function.
>>
>>     They're expected to create Layers, which can be related
>>     hierarchically as
>>     needed (or perhaps more generally, cf. #NonHierarchicalLayers [1]).
>>
>>     >            If there is a deliberate intention that the Jigsaw system
>>     > will not support dynamic modification of layers/configurations
>>     > (including the dynamic addition and removal of modules at run time),
>>     > then that should be explicitly stated.
>>
>>     I don't think it makes sense for Configurations to be mutable, for the
>>     reasons stated above.  It may be that the Layer concept needs to be
>> made
>>     more dynamic in certain ways, but that's a different matter.
>>
>>     I intend to close this issue unless there are strong objections from
>>     other EG members.
>>
>>     - Mark
>>
>>
>>     [1]
>>
>> http://openjdk.java.net/projects/jigsaw/spec/issues/#NonHierarchicalLayers
>>
>>
>>
> --
> - DML
>