Thanks for calling this out - it has been reported as
https://github.com/gwtproject/gwt/issues/9840 (and earlier), and
as time permits I've spent some effort trying to better
understand it and fix it. TL;DR: The code here is harder to read
than usual due to some questionable variable naming choices, but
seems rooted in an attempt to optimize by not running all of the
JsInliner on the entire program, resulting in missing cases like
this. I have a patch that appears to fix it (and makes sense
logically), and is just missing some tests to be sure.
Part of the problem here for code that never converges is that
the compiler's "optimization level" tracker believes that "9" is
the largest numbers can get - when counting compiler passes. That
is, if you ask for the max optimization level, that value is "9",
and if after 9 passes the compiler hasn't converged, it will keep
going. Some quick testing suggests that 8-11 passes seems "pretty
good as a max", but I think this means the max should have been
99 (or higher) so that at some point it actually gives up. No
error is required here, just "stop, this is pointless" - and
likewise, no timeout.
There's technically another heuristic that the Java optimization
loop uses, checking if the number of nodes changed/removed is
higher than the required baseline rate:
float nodeChangeRate = stats.getNumMods() / (float)
lastNodeCount;
float sizeChangeRate = (lastNodeCount - nodeCount) /
(float) lastNodeCount;
if (nodeChangeRate <= minChangeRate && sizeChangeRate <=
minChangeRate) {
break;
}
https://github.com/gwtproject/gwt/blob/552c72eaa555a521d2e242d277273217704c1ed7/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#L1440-L1444
Unfortunately, once you've hit "9" as your optimization level,
this is fixed at "any change at all is good, keep going".
Further, even if we did have a slightly higher baseline rate
configured, the JS optimization loop only counts passes, not
change rate:
if ((optimizationLevel < OptionOptimize.OPTIMIZE_LEVEL_MAX
&& counter > optimizationLevel)
|| !stats.didChange()) {
break;
}
https://github.com/gwtproject/gwt/blob/552c72eaa555a521d2e242d277273217704c1ed7/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#L1004-L1007
And as it happens, that's where the bug is, in optimizing JS, not
Java.
I've mused about adding a timeout option also, something like
"whatever you've gotten done in 30s is good enough, give up", but
the use case is a little weird - impatient devs who still want
optimized code, and nondeterministic (but still correct) output?
Seems like a recipe for frustration, but that's just my two cents.
As part of this and some other optimization pass enhancements,
I'm hoping to improve both how we collect metrics on the compiler
performance and how we debug the work it actually does, so that
we can more confidently make changes in this area, or at least
make it easier for users to report what they're seeing without
sharing their entire codebase.
On Wednesday, November 5, 2025 at 1:27:03 PM UTC-6 Michael Joyner
wrote:
Hello all,
I had a recursive setter get created while switching a
field’s name.
I ended up with:
|public void setSearchTerm(String searchTerm) {
setSearchTerm(searchTerm); } |
And the gwtCompile just stops and sits there… (I presume
after a very very very very long time it would error out?)
Is this a known bug? Feature?
-Mike
​
--
You received this message because you are subscribed to the
Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/google-web-toolkit/0938f2a8-7abc-4e48-8d0a-2c90e08c9e95n%40googlegroups.com
<https://groups.google.com/d/msgid/google-web-toolkit/0938f2a8-7abc-4e48-8d0a-2c90e08c9e95n%40googlegroups.com?utm_medium=email&utm_source=footer>.
