XPConnect that is soon to be fixed, but also allows us to take advantage
of the XPConnect caching, and to save rebuilding the same class info for
short-lived objects created repeatedly.
Not part of the build.
git-svn-id: svn://10.0.0.236/trunk@103159 18797224-902f-48f8-a5cc-f745e15eee43
in the case where the socket gets closed we need to remove it from the
connection cache. more work needs to be done to properly clean up
the protocol instance and to fix some related issues, but this helps
the end user. r=bienvenu, sr=sspitzer. thanks to Phil Anderton
for the patch.
git-svn-id: svn://10.0.0.236/trunk@103155 18797224-902f-48f8-a5cc-f745e15eee43
Fix for bug #80239: javascript strict warnings in editor.js
Simplify methods that check for existence of
spellchecker and find components, by checking
if they exist in Components.classes.
r=cmanske@netscape.comsr=kin@netscape.com
git-svn-id: svn://10.0.0.236/trunk@103130 18797224-902f-48f8-a5cc-f745e15eee43
liked by it.
so what I did was remove 2 instances of "for (int i = <blah>"
and replaced it with "int i; <blah> for (i = <blah>"
git-svn-id: svn://10.0.0.236/trunk@103092 18797224-902f-48f8-a5cc-f745e15eee43
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
git-svn-id: svn://10.0.0.236/trunk@103090 18797224-902f-48f8-a5cc-f745e15eee43
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
git-svn-id: svn://10.0.0.236/trunk@103089 18797224-902f-48f8-a5cc-f745e15eee43
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".
git-svn-id: svn://10.0.0.236/trunk@103088 18797224-902f-48f8-a5cc-f745e15eee43
Updates for *extensions*/ctl for prabhat@Sun, r=ftank for check-in
A Incorporate frank's review fixes (08/07)
B Bugfix in TIS620Encoder
C Fix memory corruption
D Makefile changes in pangoLite directory to install pango.modules
git-svn-id: svn://10.0.0.236/trunk@103086 18797224-902f-48f8-a5cc-f745e15eee43
