Concerns mapping existing dynamic module systems to a 1-1 Module->Layer

[David M. Lloyd]

On 03/09/2017 01:16 PM, David M. Lloyd wrote:
> On 03/09/2017 01:06 PM, mark.reinhold at oracle.com wrote:
>> 2017/3/8 14:17:03 -0800, david.lloyd at redhat.com:
>>> ...
>>>
>>> This additional complexity that these extra methods is supposed to
>>> introduce has never been quantified.  The only concrete measure we have
>>> right now is the dozen-odd lines of code that the proposed patch would
>>> add.  If we can't concretely quantify this complexity, and it is the
>>> justification for denying this request, then we cannot reach consensus
>>> because there's no way to have a rational discussion about it.
>>
>> You are asking for the impossible.  I could quantify this complexity
>> today, but that would tell us very little about the future.  I cannot
>> peer into the future, inspect all plausible evolutionary timelines of
>> the Java SE Platform, and come back to you with any kind of measurement
>> of the potential long-term impact of these additional methods.
>>
>> What I can do is apply my judgement and experience, together with that
>> of engineers who have vastly more experience than I -- or you -- in the
>> implementation of high-performance, production-quality JVMs.
>>
>> You are free to disagree with the conclusion that I have reached by this
>> method, but that does not mean that rational discussion is not possible.
>
> Then there must be *some* concrete basis from which discussion can
> commence.  Can it be shown that adding these methods can even
> *theoretically* cause problematic deoptimizations that are not already
> caused just by nature of having dynamic Layers to begin with?
>
> Can it be shown that it's even remotely possible to perform AOT or any
> other kind of specialized optimizations on dynamically-generated
> Layers... even *without* the patch?   Are there even any hypotheses as
> to what problems could occur once these methods are in play, bearing in
> mind that neither the JDK nor the application module path have exposed
> Controllers and thus cannot be said to be constrained by them?
>
> Is there some other categorical consideration beyond AOT and JIT
> optimizations that your experience or those around you is suggesting
> makes this a specific problem?

Put another way.  It's provable that adding layer controller methods 
cannot impact either boot layer modules or application modules, whether 
they are in the same or differing layers.  This derives from the simple 
fact that the controllers are not available for these layers.

It's already unlikely that dynamic layers can work with AOT compilation, 
simply because the AOT compiler cannot predict how dynamic layers are 
going to interact with lower layers.  Solving this would require magic, 
as far as I can tell.  So AOT and optimization cannot be the reason to 
reject this.  No JVM people I've interacted with have provided any clues 
as to why this is even potentially harmful to the future of the JVM.

You've argued that this is not a core requirement.  However I've argued 
that it *is* a core requirement.  Other experts have also argued that it 
is a core requirement.  Members of the community are arguing that it's a 
core requirement.  Basically everyone who has discussed this publicly 
has agreed that this is needed and useful except for you.  We've made it 
very clear that we consider this a necessity to satisfy dynamic 
configuration.

You've argued that this adds unknown unknowns in the future.  But in 
light of the many other changes which are at least equally as impactful, 
there appears to be nothing that makes this particular change that 
crosses any concrete line into blanket unacceptability, or at least 
nothing that you've shared thus far.  Obviously you cannot look into the 
future.  But that doesn't lighten the burden on you to explain why you 
oppose this change.

I understand that this is not something you find useful.  I understand 
that this issue (and others as well) go against your personal feelings 
about how software ought to work.  But there is a lot of valid knowledge 
and experience that does not necessarily align with yours.  And I don't 
think I'm out of line to ask to stow the hand-waving/appeals to 
authority and at least discuss these ideas on their *actual* merits and 
drawbacks.  Every time you unilaterally decide that an issue has no need 
for further discussion, when clearly more discussion is warranted, the 
process gets subverted a little bit more.

Every time you've unilaterally rejected an issue, we've come back with a 
new way to attempt to solve the same problems that we see, which we've 
been talking about for many years now.  We've given ground on real 
mutability in favor of the second-class approach of using Layers 
everywhere for everything.  Our best case is far from optimal but we 
(and Thomas and IBM, I think) have been willing to explore other 
proposals, but you've relentlessly rejected every workable idea.

The JCP is not a rubber stamp, nor is it a free community design review 
for already-completed software projects.  It's a collaborative process 
that is meant to take *advantage* of the broad experience of the 
community to arrive at better, more powerful software than one single 
group alone could produce.  We're all trying to make this specification 
*better* and suitable for real-world use cases, and I wish I could find 
a way to make you see that.

-- 
- DML