Concerns mapping existing dynamic module systems to a 1-1 Module->Layer
David M. Lloyd
david.lloyd at redhat.com
Fri Mar 10 18:53:16 UTC 2017
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
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.
More information about the jpms-spec-observers