Details

    • Subcomponent:
    • Resolved In Build:
      b81
    • Verification:
      Verified

      Backports

        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).

          Issue Links

            Activity

            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/891db670a8cb
            User: mcimadamore
            Date: 2015-08-31 14:50:50 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/891db670a8cb User: mcimadamore Date: 2015-08-31 14:50:50 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/891db670a8cb
            User: lana
            Date: 2015-09-09 21:33:18 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/891db670a8cb User: lana Date: 2015-09-09 21:33:18 +0000
            Hide
            coffeys Sean Coffey added a comment -
            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$
            Show
            coffeys Sean Coffey added a comment - 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$
            Hide
            coffeys Sean Coffey added a comment -
            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.
            Show
            coffeys Sean Coffey added a comment - 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.

              People

              • Assignee:
                mcimadamore Maurizio Cimadamore
                Reporter:
                shadowbug Shadow Bug
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: