That's certainly an option (and might make sense if you can't find the bug in the future), but unless you want to have a stack overflow waiting to happen in your JS, I'd instead suggest fixing the method that calls itself with no possibility of escape.
I think fixing setSearchTerm probably makes more sense. On Wednesday, November 5, 2025 at 3:18:12 PM UTC-6 Michael Joyner wrote: > so… I should set my optimize to level 8 or less as a work around? > > This also impacts PRETTY mode? > > On 11/5/25 14:58, Colin Alworth wrote: > > 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> > . > > ​ > -- 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/fd7d23f9-ee58-4d2e-839d-fc064a903b17n%40googlegroups.com.
