'byfile' compilation policy
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Apr 28 08:55:02 UTC 2016
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,
More information about the compiler-dev
mailing list