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".
Hi, Norris!
I have found few problems with NativeArraj.java.
1. jsSet_length requires that the new length value should be an instance of Number. But according to Ecma 15.4.5.1, item 12-13, an error should be thrown only if ToUint32(length_value) != ToNumber(length_value). Here is a simple test that demonstrates it:
Array(5).length = new Number(1)
It currenly throws an exception.
2. jsSet_length when executing the code marked with "// assume that the representation is sparse" effectively removes all properties with values less then the current length when String is used to represent its value. Note that simply changing lines "if (d == d && d < length) delete(id);" to "if (d == d && d >= longVal) delete(id);" is not good because it would remove properties like "4.5" or "007", the full array index check has to be used instead.
Here is a test case that catches the problem:
var BIG_INDEX = 4294967290;
var a = Array(BIG_INDEX);
a[BIG_INDEX - 1] = 'a';
a[BIG_INDEX - 10000] = 'b';
a[BIG_INDEX - 0.5] = 'c';
a.length = BIG_INDEX - 5000;
var s = '';
for (var i in a) s += a[i];
print('s="'+s+'"');
this should print s='cb' (or 'bc': EcmaScript does not fix the order), but currently it gives s=''.
3. There are race conditions in jsSet_length and getIds.
The first contains:
if (hasElem(this, i))
ScriptRuntime.delete(this, new Long(i));
which would lead to call to delete in the Array prototype if 2 threads would invoke this code. Simply calling ScriptableObject.delete without any checks for existence is enough here.
getIds assumes that the count of present elements in the dense array does not change, which is not true when another thread deletes elements from dense.
The attached patch fixes these issues.
Regards, Igor
create a long chain of removed sentinels. Also, when adding k to a table
where k is not mapped, but where k hashes to a chain that includes removed
sentinels, recycle the first removed sentinel in the chain for k's entry.
2. Cache cx->resolving till js_DestroyContext, to avoid high JSDHashTable
new/destroy overhead in js_LookupProperty.
3. Add NS_TraceStack to nsTraceMalloc.[ch] and clean the .c file up a bit.
It would be nice if the rhino shell would accept a URL as the source
for javascript.
I've added this feature to my local copy so that I can launch rhino
with js scripts using JavaWebStart.
Below is a context diff of the changes I made to
toolsrc/org/mozilla/javascript/tools/shell/Main.java
There is a bug in the JavaMembers class called to wrap a Java object.
In JavaMembers.lookup(), code was added to override the static type. The
code works in the case of an Enumeration returning an Object which would
have to be casted to the appropriate type.
The code does not work when the static type is an interface. In this case,
the interface class is the one which should be reflected, not a parent class
of the dynamic type. A simple staticType.isInterface() check around the
parent traversal code fixes the problem.
Jeff
I have found a couple problems with running Rhino 1.5R2 in a heavily
multi-threaded environment. The attached patches fix the problems.
- org.mozilla.javascript.optimizer.InvokerImpl - This class was accessing
the shared classNumber outside of the synchronized block.
- org.mozilla.javascript.optimizer.OptClassNameHelper - The reset method was
not synchronized. It needs to be because the class using the classNames map
is synchronized and does not handle nulling of the variable while it's
looping on the map.
Jeff
nboyd%atg.com
brendan%mozilla.org
pschwartau%netscape.com
alecf%netscape.com
cls%seawood.org
blizzard%redhat.com
rginda%netscape.com
jband%netscape.com