I've set it to 8 and haven't really noticed any difference in performance so far in my light testing during my migration work.
I definitely appreciate all that you do and hope you have prosperity from it.
-Mike
On 11/6/25 09:48, Colin Alworth wrote:
Its my intention to fix the bug, rather than convince you to keep your application bigger and slower than it otherwise should be - but most of these changes happen in my spare time, and changing some subtle behavior of the compiler without tests sounds like a good way to cause future problems, so I'm doing it carefully. If we previously had had a way to detect and inform you, we would have shipped that.
I can't guess how much of a difference there will be in your application, you'd have to see how many loops it takes normally. As in my first message, that's one of the things I'm currently looking into improving, so that users have better visibility (if desired) into what the compiler is doing. Try it and find out?
--On Wednesday, November 5, 2025 at 6:29:37 PM UTC-6 Michael Joyner wrote:
It does. And I have. Is there that much difference between optimize level 8 versus optimize level 9?
It took me forever to find the bug though.
I'm doing a whole lot of rewrites related to converting from restygwt to domino-jackson for client side JSON serialize and deserialize. (Migrating to all Jakarta with a final goal of migrating the back-end to Spring Boot).
It would have been helpful it had errored out with (hopefully) an indication of which file was causing the issue instead of costing me most of the day being perplexed as to why it was just sitting there. If it wasn't for the IDE flagging the method as infinite recursed when I browsed that file looking for anything, I would still be stuck.
It's being a bit of a pain, as restygwt + gwt-jackson seems to support jackson annotations better than domino-jackson at this point in time and you can't have gwt-jackson at all on the classpath along with domino-jackson if using anything that inherits ObjectMapper…
On 11/5/25 16:25, Colin Alworth wrote:
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;
}
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;
}
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 google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/0938f2a8-7abc-4e48-8d0a-2c90e08c9e95n%40googlegroups.com.
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 google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/fd7d23f9-ee58-4d2e-839d-fc064a903b17n%40googlegroups.com.
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 google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/72c4cae8-a163-462c-948f-b012f9f8fa8cn%40googlegroups.com.
No comments:
Post a Comment