--- a/nashorn/docs/DEVELOPER_README	Tue Jan 29 14:25:39 2013 -0400
+++ b/nashorn/docs/DEVELOPER_README	Wed Jan 30 12:26:45 2013 +0100
@@ -36,16 +36,6 @@
 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 @@
 slots, possibly through code copying and versioning.
 
 
-SYSTEM PROPERTY: -Dnashorn.compiler.symbol.trace=<x>
+SYSTEM PROPERTY: -Dnashorn.compiler.symbol.trace=[<x>[,*]], 
+  -Dnashorn.compiler.symbol.stacktrace=[<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 @@
 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
+semantics.
 
 
 SYSTEM PROPERTY: nashorn.lexer.xmlliterals
@@ -349,6 +348,9 @@
 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 @@
 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)
-use.
+use.s
 
 
 * codegen
@@ -429,6 +431,18 @@
 
 * lower
 
+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.
+
+
+* attr
+
 The lowering annotates a FunctionNode with symbols for each identifier
 and transforms high level constructs into lower level ones, that the
 CodeGenerator consumes.
@@ -439,14 +453,11 @@
 this logger. This will probably change.
 
 
-* access
+* finalize
 
-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. 
 
 
 * fields