JDK-8132806 : javac does a naive implementation of some incorporation steps
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2015-07-31
  • Updated: 2015-11-09
  • Resolved: 2015-08-04
Related Reports
Blocks :  
Description
This code:

class ClassType<U> {
    U fu;
    ClassType() {}
    ClassType(ClassType<U> other) {
        this.fu = other.fu;
    }
    ClassType(U fu) {
        this.fu = fu;
    }
    @Override
    public String toString() {
        return "ClassType: " + String.valueOf(fu);
    }
}

public class Hang {
    static <U> ClassType<U> m(ClassType<U> src) {
        return new ClassType<U>(src);
    }

    public static void main(String argv[]) {
        ClassType<Number> c = m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>(m(new ClassType<>())))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))));
        String result = c.toString();
        if (!result.equals("ClassType: null")) {
            throw new Error();
        }
    }
}

Takes forever to be compiled. Main reason naive implementation of some incorporation steps. A huge speed-up can be obtained if some heavy operations like type substitution are not executed for those cases when they imply a no-op
Comments
I suggest playing with examples that do not involve speculative attribution - such as the one in JDK-8048838. That way, it should be easier to separate the speculative attribution concern from the type inference concern and fix them independently.
11-08-2015

Fixed in the TA repo
04-08-2015

Well w/o TA the hotspot is in the speculative attribution not at the inference step, so a fix for this issue has to wait till TA is in place.
31-07-2015