'byfile' compilation policy

[Liam Miller-Cushon]

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160427/94dbd72d/attachment.html>