'byfile' compilation policy

[Maurizio Cimadamore]

Hi Liam,
the approach you put forward seems sensible; one alternate approach 
would be to let the entire compilation unit through until Gen if a 
dependency is encountered rather than stopping at desugar - but I assume 
that's what you said it's problematic because of cycles?

A meta-question: is it still worthwhile to have separate compilation 
policies? I see that at least two of them (ATTR_ONLY and CHECK_ONLY) can 
probably be replaced by other options (i.e. -XDshouldStop) - are there 
significant use cases out there relying on either byfile or simple? 
Given that, as it has been observed, javac will need to bypass the 
compilation policy anyway to guarantee the correctness of the generated 
code (i.e. that supertypes are desugared before subtypes) - can a client 
really blindly rely on the assumption that a compilation policy does 
what it says on the tin?

Maurizio

On 28/04/16 01:50, Liam Miller-Cushon wrote:
> Hi, I encountered an issue with the 'byfile' compilation policy. 
> Desugaring adds additional ordering constraints so superclasses get 
> desugared first [1]. That causes classes to be processed separately 
> from their compilation unit, and breaks the ordering specified for byfile.
>
> [1] 
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/2aa0433e0add/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java#l1428
>
> Demo:
>
> $ cat A.java
> class One extends Three {}
> class Two {}
>
> $ cat B.java
> class Three {}
> class Four extends Two {}
>
> $ javac -XDcompilePolicy=byfile -XDverboseCompilePolicy A.java B.java
> [attribute One]
> [attribute Two]
> [flow One]
> [flow Two]
> // desugaring One starts, but it depends on Three
> [attribute Three]
> [flow Three]
> [desugar Three]
> // resume desugaring One
> [desugar One]
> [desugar Two]
> [generate code One]
> [generate code Two]
> // Four is compiled separately from its compilation unit
> [attribute Four]
> [flow Four]
> [desugar Four]
> [generate code Three]
> [generate code Four]
>
> We're using byfile because it allows analyzing an entire compilation 
> unit after attribution and before any lowering, like 'simple' but with 
> similar performance to 'todo'. I think using simple might be fine, but 
> I haven't done any performance analysis yet.
>
> Changing byfile to process entire compilation units in a group and 
> also desugar supertypes first appears to be impossible, because there 
> could be cycles.
>
> A partial fix might be to change desugar's handling of dependencies so 
> a dependency's entire compilation unit goes through flow, before the 
> dependency is desugared. That would result in something like:
>
> [attribute One]
> [attribute Two]
> [flow One]
> [flow Two]
> // desugaring One starts, but it depends on Three
> // perform attr and flow on Three and Four together
> [attribute Three]
> [attribute Four]
> [flow Three]
> [flow Four]
> // now desugar just Three
> [desugar Three]
> // resume desugaring One
> [desugar One]
> [desugar Two]
> [generate code One]
> [generate code Two]
> // Four is desugared separately from its compilation unit
> [desugar Four]
> [generate code Three]
> [generate code Four]
>
> Does the partial fix sound worthwhile?
>
> Thanks,