8007062: Split Lower up into Lower/Attr/FinalizeTypes. Integrate AccessSpecalizer into FinalizeTypes. Summary: Lower suffered from being a "God class" trying to do everything at once. As Nashorn code generation has grown, so has Lower. It does several post processing passes, tries to do several things at once even though all type information isn't in place, adjusting state afterwards and so on. It also performs control flow analysis, type attribution and constant folding, and everything else code generation related before byte code emission. I have now separated the compilation process into Lower (create low level nodes from high level ones, copy code such as finally block inlining etc), Attr (assign types and symbols to all nodes - freeze slot and scope information) and FinalizeTypes (insert explicit casts, specialize invoke dynamic types for scope accesses). I've removed the kludgy AccessSpecializer, as this now integrates naturally with typing. Everything is now much easier to read and each module performs only one thing. I have added separate loggers for the separate tiers. In the process I have also fixed: (1) problems with type coercion (see test/script/basic/typecoercion.js, basically our coercion was too late and our symbol inference was erroneous. This only manifested itself in very rare occasions where toNumber coercion has side effects, such as for example when valueOf is overridden) (2) copying literal nodes (literal copy did not use the superclass copy, which made all the Node specific fields not to be copied (3) erroneous literal tokenization (literals shouldn't always just inherit token information from whatever node that creates them) (4) splitter weighnodes - unary nodes were considered weightless (4) removed the hateful and kludgy "VarNode.shouldAppend", which really isn't needed when we have an attribution phase that determines self reference symbols (the only thing it was used for) (5) duplicate line number issues in the parser (6) convert bug in CodeGenerator for intermediate results of scope accesses (see test/script/basic/access-specializer.js) ... Several of these things just stopped being problems with the new architecture "can't happen anymore" and are not bug fixes per se. All tests run. No performance regressions exist that I've been able to measure. Some increases in performance were measured, but in the statistical margin of error (which is very wide as HotSpot currently has warmup issues with LambdaForms/invoke dynamic). Compile speed has not measurably increased. Reviewed-by: jlaskey, attila

     1

/*

     2

 * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved.

     3

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

     4

 * 

     5

 * This code is free software; you can redistribute it and/or modify it

     6

 * under the terms of the GNU General Public License version 2 only, as

     7

 * published by the Free Software Foundation.

     8

 * 

     9

 * This code is distributed in the hope that it will be useful, but WITHOUT

    10

 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

    11

 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

    12

 * version 2 for more details (a copy is included in the LICENSE file that

    13

 * accompanied this code).

    14

 * 

    15

 * You should have received a copy of the GNU General Public License version

    16

 * 2 along with this work; if not, write to the Free Software Foundation,

    17

 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

    18

 * 

    19

 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA

    20

 * or visit www.oracle.com if you need additional information or have any

    21

 * questions.

    22

 */

    23

    24

/**

    25

 * This is a simple test that checks that access specialization in FinalizeTypes is consistent.

    26

 * Here, a2 = 0 will be turned int {I}a2 = 0, and all would be fine and well, only we can't change

    27

 * the symbol type for a2 from double, and we can't as it's not a temporary. Either we have to put 

    28

 * a temporary in at the late finalize stage and add another assignment, or we genericize the check

    29

 * in CodeGenerator#Store so we detect whether a target is of the wrong type before storing. It 

    30

 * is hopefully very rare, and will only be a problem when assignment results that have been

    31

 * specialized live on the stack

    32

 *

    33

 * @test

    34

 * @run

    35

 */

    36

    37

function f() {

    38

    var a0 = a1 = a2 = 0;

    39

    a0 = 16.1;

    40

    a1 = 17.1;

    41

    a2 = 18.1;

    42

}

    43

f();