Problem when set optimization level to 9 with GWT 2.8 #9452
Comments
|
With optimize 9 GWT optimizes the code in a loop until the AST does not change anymore. Unfortunately in very rare cases this loop will never stop. This issue exists for quite some time now (not just in GWT 2.8), but I guess nobody has an idea what is causing it. With optimize 8 all optimizations will be done at most 8 times or until the AST does not change anymore, whatever comes first. |
|
Also, I'm having this warning: [INFO] [WARN] Lost communication with remote process I don't know if it's related to above issue |
|
I believe the DataFlowOptimizer is the only optimization that is not convergent (see https://gwt-review.googlesource.com/#/c/4061/). BTW at Google is turned off by default (independent of the -optimize level). I personally have not seen the issue of non terminating loop when this pass is off. That being said I don't think the StackOverflowException and the main optimization loop non terminating due to non convergence are related. The SOE indicates more likely a bug in the pass JsInliner (which does the inline of functions in GWT's JavaScript AST). Could you post a more complete stack trace? |
|
I'm seeing this too (with the DataFlowOptimizer turned off) with 2.8.1. Debugging the compiler, it spins inside the optimizeJsLoop method of JavaToJavaScriptCompiler, with the JsInliner always reporting changes on each loop (even after 100+ loops). I'm happy to give more info, but don't know enough about how the compiler (or the JsInliner) works to know what would be useful. |
|
@garethl did disabling the dataflowoptimizer pass work for you? I realize from Roberto's comment that it is unlikely, but it seems worth checking. My next thought would be to alter |
|
@niloc132, yes, with it disabled (i.e. passing in -XnooptimizeDataflow to the compiler), I'm still seeing it getting stuck. For now, I've dropped the optimize flag down to 8, which lets me continue, but would be nice to get to the bottom of this. Will see what I can dig up by going through that replaceMe method (have already done some poking around there). Yea, unfortunately, cannot share the code - it is a rather large project that is probably > 100k lines too. |
|
JsInliner runs way after the problematic dataflow pass. I guess there is
some recursive method (maybe two, three mutually recursive functions) that
gets inlined over and over and not properly avoided.
…On Wed, Mar 28, 2018 at 4:44 AM Colin Alworth ***@***.***> wrote:
@garethl <https://github.com/garethl> did disabling the dataflowoptimizer
pass work for you? I realize from Roberto's comment that it is unlikely,
but it seems worth checking.
My next thought would be to alter JsModVIsitor.replaceMe to log, or add a
breakpoint so that you can make it print out the code it changed (before
and after), and look for it to keep rewriting the same code, etc. Perhaps
don't bother enabling this logging until it has run for 10-100 times, so
that most of the "real" changes have already been made, and hopefully there
is only the one broken one left. This might be helpful to build a simple
example if you can't share the code in your project that causes the issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#9452 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD-2lBM8StAU1e-jwN5ilFGQIXrGAy6tks5ti3edgaJpZM4KsIHd>
.
|
|
We started to see this with both 2.8.2 and current master on our legacy project. Switching optimization level to 8 works as a workaround. |
|
So, no, sorry, it was endless recursion in our case #9647 |
If i set it to level 8, it compiles in 4 minutes. With level 9 it crash with this stacktrace:
[INFO] Replacing GWT.runAsync with island loader calls
[INFO] Looking up initial load sequence for split points
[INFO] Initial load sequence of split points: (none)
[INFO] removing source artifacts
[INFO] Compiling 14 permutations
[INFO] Creating worker permutation 0 of 14
[INFO] Creating worker permutation 1 of 14
[INFO] Creating worker permutation 2 of 14
[INFO] Creating worker permutation 3 of 14
[INFO] Creating worker permutation 4 of 14
[INFO] Creating worker permutation 5 of 14
[INFO] Creating worker permutation 6 of 14
[INFO] Creating worker permutation 7 of 14
[INFO] Creating worker permutation 8 of 14
[INFO] Creating worker permutation 9 of 14
[INFO] Creating worker permutation 10 of 14
[INFO] Creating worker permutation 11 of 14
[INFO] Creating worker permutation 12 of 14
[INFO] Creating worker permutation 13 of 14
[INFO] Creating PermutationWorkerFactory instances
[INFO] javaCommand = /opt/jdk1.8.0_112/jre/bin/java
[INFO] Process output
[INFO] Compiling permutation 1...
[INFO] Socket opened
[INFO] Compiling
[INFO] Compiling permutation 0...
[INFO] Permutation took 27185611 ms
[INFO] [ERROR] StackOverflowError: Increase stack size
[INFO] java.lang.StackOverflowError
[INFO] at java.util.ArrayList.(ArrayList.java:177)
[INFO] at com.google.gwt.thirdparty.guava.common.collect.Lists.newArrayList(Lists.java:146)
[INFO] at com.google.gwt.dev.js.JsInliner$InliningVisitor.process(JsInliner.java:890)
[INFO] at com.google.gwt.dev.js.JsInliner$InliningVisitor.endVisit(JsInliner.java:798)
[INFO] at com.google.gwt.dev.js.ast.JsInvocation.traverse(JsInvocation.java:91)
I've try to increase Xss from 128k to 4m and get same results.
I've try to decrease localWorkers to only one and same results.
This is the maven compiler command:
/bin/sh -c '/opt/jdk1.8.0_112/jre/bin/java' '-Xmx4g' '-Xms4g' '-Xss16m' '-Dgwt.persistentunitcache=true' 'com.google.gwt.dev.Compiler' '-logLevel' 'INFO' '-war' '/opt/workspace/kyrian/portal-prj/absentismo-prj/absentismo-war/target/absentismo-war' '-localWorkers' '1' '-failOnError' '-compileReport' '-XfragmentCount' '-1' '-sourceLevel' '1.8' '-style' 'OBF' '-optimize' '9' '-extra' '/opt/workspace/kyrian/portal-prj/absentismo-prj/absentismo-war/target/extra' '-gen' '/opt/workspace/kyrian/portal-prj/absentismo-prj/absentismo-war/target/.generated' 'org.mutua.app.absentismo.AbsentismoProduction'I'm doing something wrong?
The text was updated successfully, but these errors were encountered: