30b950d2d2
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 |
||
---|---|---|
.. | ||
.jcheck | ||
bin | ||
buildtools/nasgen | ||
docs | ||
make | ||
makefiles | ||
samples | ||
src | ||
test | ||
.hgignore | ||
.hgtags | ||
ASSEMBLY_EXCEPTION | ||
LICENSE | ||
README | ||
RELEASE_README | ||
THIRD_PARTY_README |
- What is Nashorn? Nashorn is a runtime environment for programs written in ECMAScript 5.1 that runs on top of JVM. - How to find out more about ECMAScript 5.1? The specification can be found at http://www.ecma-international.org/publications/standards/Ecma-262.htm - How to checkout sources of Nashorn project? Nashorn project uses Mercurial source code control system. You can download Mercurial from http://mercurial.selenic.com/wiki/Download Information about the forest extension can be found at http://mercurial.selenic.com/wiki/ForestExtension and downlaoded using hg clone https://bitbucket.org/gxti/hgforest You can clone Nashorn Mercurial forest using this command: hg fclone http://hg.openjdk.java.net/nashorn/jdk8 nashorn~jdk8 To update your copy of the forest (fwith the latest code: (cd nashorn~jdk8 ; hg fpull) Or just the nashorn subdirectory with (cd nashorn~jdk8/nashorn ; hg pull -u) To learn about Mercurial in detail, please visit http://hgbook.red-bean.com. - How to build? To build Nashorn, you need to install JDK 8. You may use the Nashorn forest build (recommended) or down load from java.net. You will need to set JAVA_HOME environmental variable to point to your JDK installation directory. cd nashorn~jdk8/nashorn/make ant clean; ant - How to run? Use the jjs script (see RELESE_README): cd nashorn~jdk8/nashorn sh bin/jjs <your .js file> Nashorn supports javax.script API. It is possible to drop nashorn.jar in class path and request for "nashorn" script engine from javax.script.ScriptEngineManager. Look for samples under the directory test/src/jdk/nashorn/api/scripting/. - Documentation Comprehensive development documentation is found in the Nashorn JavaDoc. You can build it using: cd nashorn~jdk8/nashorn/make ant javadoc after which you can view the generated documentation at dist/javadoc/index.html. - Running tests Nashorn tests are TestNG based. Running tests requires downloading the TestNG library and placing its jar file into the lib subdirectory: # download and install TestNG wget http://testng.org/testng-x.y.z.zip unzip testng-x.y.z.zip cp testng-x.y.z/testng-x.y.z.jar test/lib/testng.jar After that, you can run the tests using: cd make ant test You can also run the ECMA-262 test suite with Nashorn. In order to do that, you will need to get a copy of it and put it in test/script/external/test262 directory. A convenient way to do it is: hg clone http://hg.ecmascript.org/tests/test262/ test/script/external/test262 Alternatively, you can check it out elsewhere and make test/script/external/test262 a symbolic link to that directory. After you've done this, you can run the ECMA-262 tests using: cd nashorn~jdk8/nashorn/make ant test262 These tests take time, so we have a parallelized runner for them that takes advantage of all processor cores on the computer: cd nashorn~jdk8/nashorn/make ant test262parallel - How to write your own test? Nashorn uses it's own simple test framework. Any .js file dropped under nashorn/test directory is considered as a test. A test file can optionally have .js.EXPECTED (foo.js.EXPECTED for foo.js) associated with it. The .EXPECTED file, if exists, should contain the output expected from compiling and/or running the test file. The test runner crawls these directories for .js files and looks for JTReg-style @foo comments to identify tests. * @test - A test is tagged with @test. * @test/fail - Tests that are supposed to fail (compiling, see @run/fail for runtime) are tagged with @test/fail. * @test/compile-error - Test expects compilation to fail, compares output. * @test/warning - Test expects compiler warnings, compares output. * @test/nocompare - Test expects to compile [and/or run?] successfully(may be warnings), does not compare output. * @subtest - denotes necessary file for a main test file; itself is not a test. * @run - A test that should be run is also tagged with @run (otherwise the test runner only compiles the test). * @run/fail - A test that should compile but fail with a runtime error. * @run/ignore-std-error - script may produce output on stderr, ignore this output. * @argument - pass an argument to script. * @option \ - pass option to engine, sample. /** * @option --dump-ir-graph * @test */