JDK-8134007 : Improve string folding
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-08-20
  • Updated: 2016-04-27
  • Resolved: 2015-08-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u101Fixed 9 b81Fixed
Related Reports
Relates :  
JDK-8142440 - String folding stops when a non-constant object is reached
Description
Javac string folding implemented in the parser could use some improvements. Currently, given a concat of the kind:

String1 + String2 + String3 ..... + StringN

This is either left untouched (if there's an X such that StringX is not a literal) or it is all folded into a single StringRes.

A better implementation would be to generalize this to have folding to return:

StringRes1 + StringRes2 + .... StringResM

Where some of the expressions in the result are the concatenation of some of the original input strings, while some other expressions are left alone (i.e. the ones that are not ident). In chronic cases like the one in this bug, this should allow for quite a big boost (as the identifiers are only used once and in close proximity).
Comments
one possible workaround when encountering this issue : comment from Dev : === Given the intermittent nature of the problem, I believe this could be a genuine stack overflow - i.e. the stack used by javac is bigger than the one allocated by the VM; this doesn't happen under normal circumstances but, given the compiler is mostly recursive (and lack of tail call optimizations in the VM) - if you have deeply nested expressions (methods inside methods inside methods...) the compiler can end up using a lot of stack. I suggest trying with the option -J-Xss2048k (or more) - and see if the problem is resolved/less likely to occur.
23-11-2015
Adding some background information to this bug report (for completeness) ======= Original report : While compiling a java file we are seeing a intermittent exception from 'javac'. Error: top of the stack when javac failes: The system is out of resources. Consult the following stack trace for details. java.lang.StackOverflowError at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scanExpr(Flow.java:1623) at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitBinary(Flow.java:2371) at com.sun.tools.javac.tree.JCTree$JCBinary.accept(JCTree.java:1785) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404) at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382) at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scanExpr(Flow.java:1624) at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitBinary(Flow.java:2371) at com.sun.tools.javac.tree.JCTree$JCBinary.accept(JCTree.java:1785) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:404) at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1382) at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scanExpr(Flow.java:1624) at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitBinary(Flow.java:2371) at com.sun.tools.javac.tree.JCTree$JCBinary.accept(JCTree.java:1785) version details: bash-3.2$ uname -a SunOS slc03dwq 5.10 Generic_148888-02 sun4v sparc sun4v bash-3.2$ cat /etc/release Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved. Assembled 17 January 2013 . . bash-3.2$ /scratch/akaimale/view_storage/akaimale_xdk_sol/jdk8/bin/javac -version javac 1.8.0_45 bash-3.2$ /scratch/akaimale/view_storage/akaimale_xdk_sol/jdk8/bin/java -version java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) bash-3.2$
23-11-2015