Note form omj/Parser.java:
* OPT source info collection is a potential performance bottleneck;
* Source wraps a java.lang.StringBuffer, which is synchronized. It
* might be faster to implement Source with its own char buffer and
* toString method.
It is indeed a bottleneck under JDK 1.1. When I replaced StringBuffer
by a char array (see the attached patch), execution time of
Context.compileReader decreased by 15%: to test I combined a few test
cases to get a 3MB JS source and then measured time to process it by
Context.compileReader in the interpreter mode.
Under JDK 1.3 the difference is less then 1%, but still using the explicit
string buffer saves memory. When converting StringBuffer to String Sun JDK
shares the internal char array in StringBuffer with new String, but in the
Parser case typically the capacity of this buffer is bigger then the actual
string length, so this unused space in source strings is wasted in the
interpreter mode that keeps these strings in InterpreterData.
Regards, Igor
========
I implemented that member expression as function name syntactic sugar to
support scripts using this MS extension. This is only available when
Context.hasFeature(Context.FEATURE_MEMBER_EXPR_AS_FUNCTION_NAME)
returns true to allow the deviation from the standard only when required.
The patch effectively transforms 'function <memberExpr>(...)...' to
'<memberExpr> = function(...)...' when <memberExpr> is not simple
identifier. I am not sure that MS implementation does exactly this
but hopefully it is sufficiently general to cover MS cases.
(The patch assumes that source_change.patch is already applied)
Regards, Igor
I implemented that member expression as function name syntactic sugar to support
scripts using this MS extension. This is only available when
Context.hasFeature(Context.FEATURE_MEMBER_EXPR_AS_FUNCTION_NAME)
returns true to allow the deviation from the standard only when required.
The patch effectively transforms 'function <memberExpr>(...)...' to
'<memberExpr> = function(...)...' when <memberExpr> is not simple identifier.
I am not sure that MS implementation does exactly this but hopefully it is
sufficiently general to cover MS cases.
(The patch assumes that source_change.patch is already applied)
Regards, Igor
Currently omj/TokenStream and omj/optimizer/Optimizer.java both contain
code to convert number value to a wrapper object of smallest size. The
attached patch moves this wrapping to Node constructor to avoid code
duplication and eliminate special treatment of exact integers in
Optimizer.java.
The constant folding code in omj/optimizer/Optimizer.java currently always
replaces x * 1, x - 0 by simply x which does not force the toNumber convertion,
which is visible, for example, via typeof. For example, when running at
optimization level 2, the following
function f() {
return "0" * 1;
}
print(typeof(f()));
prints "string" instead of expected "number".
The const_fold.patch fixes this via replacing x*1 by (+x) to force number convertion.
It assumes that the patch with number wrapping changes is in place.
convert number value to a wrapper object of smallest size. The attached patch
moves this wrapping to Node constructor to avoid code duplication and eliminate
special treatment of exact integers in Optimizer.java.
Currently omj/optimizer/Codegen.java uses special classes ConstantList
and ConstantDude to store the list of static constants in the generated
class. It seems that using a simple double[] array with a constant
counter and checking via "(int)number == number" for constant types not
only eliminates these 2 classes but makes the whole code simple, see
the attached patch.
The patch also modifies nodeIsConvertToObjectOfNumber to return not a
Number, but the number node itself that is used to extract double
value directly via Node.getDouble() call. I changed it to allow to
store values of number literals in nodes without using wrapper object.
Replacing usage of ShallowNodeIterator to loop throw node children by
explicit calls to Node.getFirstChild()/ Node.getNextSibling()) with
comments when the node children list is modified while iterating
through it.
It avoids creation of ShallowNodeIterator objects and eliminates the
need to have ShallowNodeIterator class.
Currently Rhino source has quite a few places with code like (String)node.getDatum()
or ((Number)node.getDatum()).doubleValue(). The patch changes this usage to call
node.getString() or node.getDouble().
It also adds new constructors to Node to accept int or double values in addition to
Object datum to replace new Node(token, new Integer(x)) by Node(token, x) etc. It
may allow in future not to create a wrapper object for int or double datum to speed
up parsing.
Currently in the interpreter mode all number literals are stored in
InterpreterData.itsICode as an index to InterpreterData.itsNumberTable
which holds the actual value.
For integers that fit 2 or 4 bytes this is an overkill and the attached
patch stores integers in InterpreterData.itsICode inline after special
TokenStream.INTNUMBER or TokenStream.SHORTNUMBERS tokens.
The changes made benchmarks to run 1.5% faster. It also saves memory
because InterpreterData.itsNumberTable is allocated only for non-integers
that present only in a small number of scripts.
In principle, it may be possible to store all numbers inline as well, but
unfortunately re-assembling of 8 bytes from InterpreterData.itsICode array
into double is rather slow operation and is not worth the hassles.
Regards, Igor
Hi, Norris!
Currently ScriptableObject.put does not check lastAccess cache during its search for
slots. When I added this check (see the attached patch) it speeded up the benchmark
suite by about 1.5% and in particular for setProp_bench.js the win was about 8%.
I think that even on multiprocessor machines it would not introduces any additional
issues like accessing the old value in the processor cache because the put method
accesses existing properties via unsynchronized getSlot, and the check for lastAccess
is on pair with that.
Trgards, Igor
When handling an Exception the Context tries to get the current script
and line number from the Java Stacktrace. To get the indication of which
entry in the trace might be an ECMA script, the file extension ".js" is
assumed.
For our integration we use the standard extension ".ecma" which collides
with the above assumption. But we don't force this extension, we just
have a convention. We name these files ".ecma" as they are not plain
ECMA but JSP-like ECMA. That is instead of using Java as the programming
language we use ECMA. In this respect they would be ".esp".
Patch fixes issue of not ignoring UNICODE format characters in match
and peek methods, adds explicit assertions checks for code assumptions
and makes handling of ASCII '\r', '\n' and UNICODE U+2028, U+2029 line
ends uniform.
It was rather tricky to fix format character issue and I spend some
time figuring out what TokenStream assumes about LineBuffer that
breaks my initial thoughts on the patch in cases like very long
sequences of format characters that do not fit in the buffer. I
fixed that but it made the code rather unclear so I put explicit
checks for assumptions/preconditions to help with debugging.
I added Context.check flag to turn on/off these checks and
Context.codeBug to throw an exception in case of check violations,
and also modified UintMap to use them instead of the private
flags there.
It would be nice to add some tests about format characters to the test
suite with checks similar to "eval('1 =\u200C= 1') == true" and
"eval('.\u200C1') == 0.1".
dbradley%netscape.com
gerv%gerv.net
pschwartau%netscape.com
nboyd%atg.com
shaver%mozilla.org
brendan%mozilla.org
cls%seawood.org
jband%netscape.com
rginda%netscape.com
timeless%mac.com
scc%mozilla.org
rogerl%netscape.com
jaggernaut%netscape.com
alecf%netscape.com