|author||lagergren <none@none>||2013-01-30 12:26:45 +0100|
|committer||lagergren <none@none>||2013-01-30 12:26:45 +0100|
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
Diffstat (limited to 'docs')
1 files changed, 32 insertions, 21 deletions
diff --git a/docs/DEVELOPER_README b/docs/DEVELOPER_README
index 55c41010..f628d0c0 100644
@@ -36,16 +36,6 @@ See the description of the access logger below. This flag is
equivalent to enabling the access logger with "info" level.
-SYSTEM PROPERTY: -Dnashorn.compiler.ints.disable
-This flag prevents ints and longs (non double values) from being used
-for any primitive representation in the lowered IR. This is default
-false, i.e Lower will attempt to use integer variables as long as it
-can. For example, var x = 17 would try to use x as an integer, unless
-other operations occur later that require coercion to wider type, for
-example x *= 17.1;
SYSTEM PROPERTY: -Dnashorn.compiler.intarithmetic
Arithmetic operations in Nashorn (except bitwise ones) typically
@@ -195,7 +185,8 @@ We still have to deal with objects vs primitives for local bytecode
slots, possibly through code copying and versioning.
-SYSTEM PROPERTY: -Dnashorn.compiler.symbol.trace=<x>
+SYSTEM PROPERTY: -Dnashorn.compiler.symbol.trace=[<x>[,*]],
When this property is set, creation and manipulation of any symbol
named "x" will show information about when the compiler changes its
@@ -203,8 +194,16 @@ type assumption, bytecode local variable slot assignment and other
data. This is useful if, for example, a symbol shows up as an Object,
when you believe it should be a primitive. Usually there is an
explanation for this, for example that it exists in the global scope
-and type analysis has to be more conservative. In that case, the stack
-trace upon type change to object will usually tell us why.
+and type analysis has to be more conservative.
+Several symbols names to watch can be specified by comma separation.
+If no variable name is specified (and no equals sign), all symbols
+will be watched
+By using "stacktrace" instead of or together with "trace", stack
+traces will be displayed upon symbol changes according to the same
SYSTEM PROPERTY: nashorn.lexer.xmlliterals
@@ -349,6 +348,9 @@ this system property.
2. The loggers.
+It is very simple to create your own logger. Use the DebugLogger class
+and give the subsystem name as a constructor argument.
The Nashorn loggers can be used to print per-module or per-subsystem
debug information with different levels of verbosity. The loggers for
a given subsystem are available are enabled by using
@@ -382,7 +384,7 @@ into byte code, and installs the classes into a class loader
controlled from the Context. Log messages are, for example, about
things like new compile units being allocated. The compiler has global
settings that all the tiers of codegen (e.g. Lower and CodeGenerator)
@@ -429,6 +431,18 @@ The --log=codegen option is equivalent to setting the system variable
+This is the first lowering pass.
+Lower is a code generation pass that turns high level IR nodes into
+lower level one, for example substituting comparisons to RuntimeNodes
+and inlining finally blocks.
+Lower is also responsible for determining control flow information
+like end points.
The lowering annotates a FunctionNode with symbols for each identifier
and transforms high level constructs into lower level ones, that the
@@ -439,14 +453,11 @@ specialization information. Currently very little info is generated by
this logger. This will probably change.
-The --log=access option is equivalent to setting the system variable
-"nashorn.callsiteaccess.debug" to true. There are several levels of
-the access logger, usually the default level "info" is enough
-It is very simple to create your own logger. Use the DebugLogger class
-and give the subsystem name as a constructor argument.
+This --log=finalize log option outputs information for type finalization,
+the third tier of the compiler. This means things like placement of
+specialized scope nodes or explicit conversions.