Infinite loop at compile time

[Paul Robinson]

I just found an infinite loop while running the GWT compiler.

There was a trivial bug in my code which resulted in an infinite loop at *runtime*. This is a method that was calling itself recursively. It was inside a generic class, and the method had a single line that was something like this:

public class A<T extends B> extends C {

    public static <T extends B> A<T> getA(D d, E e, F f) {

        return getA(d, e, null);

    }

}

I have been running in dev mode with it like this, but not hitting this code so I didn't notice the infinite loop.

Wanting to test GWT 2.11.0, I switched from GWT 2.10.0 and did a full GWT compile. The interesting thing is that the GWT compile also hit an infinite loop. Or rather, it was apparently infinite. I stopped it after 50 minutes, where it would normally complete in about about 90 seconds. I dropped back to 2.10.0, and found the same behaviour. So it's not caused by the new release.

Fixing the bug in my code meant it then compiled properly (in both 2.11.0 and 2.10.0).

Is this interesting enough to warrant further investigation? This is code inside a large application, so isolating a simple example that demonstrates it might not work easily.

FWIW there's a stack trace taken while stuck in the loop, compiling with 2.11.0 here: https://pastebin.com/qckpswRD

Paul

[Colin Alworth]

Thanks for reporting - perhaps better for the bug tracker, and indeed we do this (or something like it) filed already, see https://github.com/gwtproject/gwt/issues/9840.

Your email title says that this is a compile time infinite loop, but then the body suggests that it was a runtime error. If it were to be exhibited at runtime, it would almost certainly be a stackoverflow rather than looping forever (barring some sort of tail call optimization). The actual loop that you're seeing is waaay up the stack in

at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimizeJsLoop(JavaToJavaScriptCompiler.java:1001)

where the compiler decides to optimize until it reaches your optimization level, or until nothing changes. While SDM stands for "Super Dev Mode", it can also be understood to mean "Super Draft Mode", so the compiler builds as quickly and cheaply as possible, letting your app escape with very little optimization. This means that in SDM, you will not get stuck in this loop - the optimization loop won't run at all (see one frame up, shouldOptimize will return false), and you'll instead experience a stackoverflow at runtime.

I didn't continue investigation of the problem further yet, but the linked ticket does have some analysis to consider.

[Paul Robinson]

Thanks Colin. I should have looked at the issue tracker. Sorry about that.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/58e74afc-7677-4a92-8895-880d884cd802n%40googlegroups.com.