with JSRESOLVE_ASSIGNING, wrongly), plus a few miscellaneous bugfixes.
- Combine the JSStackFrame members constructing, special, overrides, and
reserved into a uint32 flags member.
- Separate JOF_ASSIGNING from the JOF_SET bytecode format flag, and impute
JSRESOLVE_ASSIGNING from the presence of JOF_ASSIGNING among the current
opcode's format flags. To handle the for-in loop opcodes, which do more
than simply assign -- in particular, they do property lookups whose resolve
hook outcalls should not be flagged with JSRESOLVE_ASSIGNING -- a new frame
flag, JSFRAME_ASSIGNING, has been added.
- Fix interpreter version selection to respect JS_SetVersion, whose effect on
cx->version is "sticky".
- Fix js_DecompileValueGenerator to deal with JSOP_ENUMELEM -- it never had,
as this testcase shows (it crashes without this patch):
version(120);
eval("function fe(s) { for (it[s] in this); }");
try { fe('rdonly'); } catch (e) { print(e); }
My optimization for PreorderNodeIterator has a bug that would cause an attempt
to access stack[-1] in
currentParent = (current == null) ? null : stack[stackTop - 1];
when current refers to a start node sibling. This is not visible in Rhino because
currently PreorderNodeIterator is always started from nodes with node.next == null.
iter.diff fixes that plus it removes currentParent field because it is always
available as stack[stackTop - 1] and code to access its value are executed less
frequently than the lines to update it in nextNode
Regarsd, Igor
As profiler data show, the execution time of the nextNode and replaceCurrent
methods in PreorderNodeIterator contribute quite significantly to the total
time to run Context.compileReader.
replaceCurrent is slow because it calls Node.replaceChild which have to
iterate through all previous siblings to find the nearest to the current.
But it is easy to avoid this search by caching the previous sibling of the
current while iterating over the node tree in nextNode.
nextNode slowness is attributed to the usage of java.lang.Stack which is
expensive due to its synchronized methods. In the attched patch I replaced
it by the explicit array management.
It allows to cut Context.compileReader time by 5%-30% when processing
20K-3MB sources assembled form JS files in the test suite.
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.
