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

David M. Lloyd david.lloyd at redhat.com
Thu Mar 9 19:16:08 UTC 2017


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?

-- 
- DML


More information about the jpms-spec-observers mailing list