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.
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".
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
- The most significant fix, to keep JSStackFrame.spbase, the operand stack base pointer for an active frame, null except when there is an operand stack allocated and in use by js_Interpret. Previously, spbase would point after args and local vars (if any), then advance upon allocation of the (possibly discontiguous) operand stack space. This made for a fatal ambiguity: js_AllocStack, called by XPConnect, could not tell when there was allocated operand stack space above the frame's sp, which needs to be set to a known (JSVAL_VOID) state for exact GC to work. Now, the GC doesn't have to mark any operand stack space for a frame whose spbase is null, and js_AllocStack doesn't need to void any unused space for such a frame.
- Fixes to reload the JSRuntime's callHook or executeHook after calling or executing, in case the debugger removes the hook. In which case, it must clean up any dynamic memory held by hookData, but in any event, in which case the engine must not call the post-call or post-execute hook.
- While debugging with rginda, I was horrified to see his trivial testcase function, expressed as a lambda, fail to be invoked using the "inline_call" machinery in js_Interpret (which avoids js_Interpret recursion through js_Invoke for most JS functions). The problem was a test of fun->flags == 0 conditioning the /* inline_call: */ code. Since that test was written, at least one JSFUN_* flag (JSFUN_LAMBDA, used only for pretty-printing or accurate decompilation) has been added. But all along, that test was an over-optimization (testing against 0 without &'ing certain flags), making for an accident waiting to happen -- which did happen. The relevant flags are JSFUN_HEAVYWEIGHT (set by the compiler when a function calls eval, uses with, or otherwise needs an activation object for its scope; if lightweight, the compiler can see the function's scope and eliminate it via specialized bytecodes) and JSFUN_BOUND_METHOD (for Java method calls, where |this| binds statically to the instance, not dynamically to the calling expression reference's base object, as in JS).
don't allow gc's during script hooks if CAUTIOUS_SCRIPTHOOK is defined (which it is, by default.) Should help with stability until we can fix the real problems.
Use JSVAL_ macros instead of JSD_* calls in jsdValue::GetJSType method, avoiding two c++ frames per call.
Also, fixes for :
#91343, (non-latin1 fails for [\S])
#78156, (Unicode line terminator matching)
#87231, (/(A)?(A.*)/ didn't reset paren state for empty first match)
improvements:
Subject:
Rhino: Problem in NativeJavaMethod
Date:
Tue, 14 Aug 2001 10:23:35 +0200
From:
felix.meschberger@day.com
To:
Norris Boyd <nboyd@atg.com>
Hi Norris,
While working with wrapped Java classes we discovered a problem in
NativeJavaMethod : If the public method to be called is part of a
non-public class, the Sun Java VM throws an IllegalAccessException. This
bug in the Sun VM has been reported as Bug 4071593 to Sun, but has not been
resolved since....
I implemented a circumvention, for which I provide you the patch. I quickly
tested it, and it seems to work.
Regards
Felix
And here's the patch :
diff -w -r1.19 NativeJavaMethod.java
227a228,234
> /**
> * Due to a bug in Suns VM, public methods in private
> * classes are not accessible by default (Sun Bug #4071593).
> * We have to explicitly set the method accessible beforehand
> */
> meth.setAccessible(true);
>
-----------------------------------------------------------------
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying to
this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble-free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:felix.meschberger@day.com
http://www.day.com
Felix Meschberger
Development
Day Interactive AG
Steinenberg 21-23
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
Rhino: Problem in NativeJavaMethod
Date:
Tue, 14 Aug 2001 10:23:35 +0200
From:
felix.meschberger@day.com
To:
Norris Boyd <nboyd@atg.com>
Hi Norris,
While working with wrapped Java classes we discovered a problem in
NativeJavaMethod : If the public method to be called is part of a
non-public class, the Sun Java VM throws an IllegalAccessException. This
bug in the Sun VM has been reported as Bug 4071593 to Sun, but has not been
resolved since....
I implemented a circumvention, for which I provide you the patch. I quickly
tested it, and it seems to work.
Regards
Felix
[Fwd: Rhino 1.5.2 bug in debug support?]
Date:
Sun, 12 Aug 2001 14:13:26 -0700
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
nboyd@atg.com
Hi Norris,
Did you or are you fixing this problem? It seems to be simply a matter
of filtering out -1 before inserting line numbers into the
lineNumberTable. In this particular case the Parser generates -1 as a
line number for (? : ) in IRFactory.createTernary(). However the recent
changes to InterpreterData to use UintMap instead of Hashtable will not
tolerate negative numbers. Changing Interpreter.updateLineNumber() and
InterpreterData.getOffset() to check for negative line numbers (and
avoid generating line number code or accessing the lineNumberTable in
that case) will correct the problem.
Chris
Subject:
Rhino 1.5.2 bug in debug support?
Date:
8 Aug 2001 12:47:28 -0700
From:
d-russo@ti.com (dave russo)
Organization:
http://groups.google.com/
Newsgroups:
netscape.public.mozilla.jseng
I'm getting the following exception when running the Rhino debugger.
java.lang.RuntimeException
at org.mozilla.javascript.UintMap.check(UintMap.java:349)
at org.mozilla.javascript.UintMap.put(UintMap.java:158)
at
org.mozilla.javascript.Interpreter.updateLineNumber(Interpreter.java:234)
at
org.mozilla.javascript.Interpreter.generateICode(Interpreter.java:300)
at
org.mozilla.javascript.Interpreter.generateICode(Interpreter.java:926)
at
org.mozilla.javascript.Interpreter.generateICode(Interpreter.java:302)
at
org.mozilla.javascript.Interpreter.generateICode(Interpreter.java:302)
at
org.mozilla.javascript.Interpreter.generateICode(Interpreter.java:302)
at
org.mozilla.javascript.Interpreter.generateICodeFromTree(Interpreter.java:89)
at
org.mozilla.javascript.Interpreter.generateFunctionICode(Interpreter.java:186)
at
org.mozilla.javascript.Interpreter.generateNestedFunctions(Interpreter.java:164)
at
org.mozilla.javascript.Interpreter.generateScriptICode(Interpreter.java:124)
at org.mozilla.javascript.Interpreter.compile(Interpreter.java:78)
at org.mozilla.javascript.Context.compile(Context.java:1810)
at org.mozilla.javascript.Context.compile(Context.java:1735)
at org.mozilla.javascript.Context.compileReader(Context.java:852)
at org.mozilla.javascript.Context.evaluateReader(Context.java:770)
at org.mozilla.javascript.tools.shell.Main.evaluateReader(Main.java:300)
at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:290)
at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:244)
at org.mozilla.javascript.tools.shell.Main.exec(Main.java:104)
at org.mozilla.javascript.tools.debugger.Main.main(Main.java:3156)
I'm using Rhino 1.5.2 prerelease
(ftp://ftp.mozilla.org/pub/js/rhino15R2pre.zip) and SUN's JDK 1.3.1
runtime for Windows.
I'm running the debugger as follows:
java -cp js.jar org.mozilla.javascript.tools.debugger.Main -f tconfini.tcf
Where the file tconfini.tcf is shown below:
function getBoard (defFile) {
if (arguments.length > 0 ) {
return (defFile != null ? defFile[1] : null);
}
return (null);
}
Any help would be appreciated. Thanks!
dave
=================================
Rhino: use of Node.get/putIntProperty to store integer values
The patch replaces usage like
node.putProp(PROPERTY, new Integer(int_value))
((Integer)node.getProp(PROPERTY))
by
node.putIntProp(PROPERTY, int_value)
node.getIntProp(PROPERTY, defaultValue)
node.getExistingIntProp(PROPERTY)
to avoid creation of Integer wrapper objects while storing integer
properties in Nodes.
Patch also ads Node.removeProp to explicitly remove Node properties
=================================
The patch changes the type of the first argument of Interpreter.addByte
from byte to int so there is no need to cast int arguments, adds
addShort(int value, int iCodeTop), getShort(byte[] iCode, int pc) to
pack/unpack short values from pc array, replaces calls to
getString(stringTable, byte[] iCode, int pc) by
stringTable[getShort(iCode, pc)] and similar for getNumber
It makes Interpreter.java easy to follow and slightly shrink its class file.
Re: Rhino 1.5R2 release candidate
Date:
Fri, 13 Jul 2001 22:52:43 -0700
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
Norris Boyd <nboyd@atg.com>
References:
1
Hi Norris,
Attached are some (final?) changes to the debugger:
- Display NativeCall objects as "[object Call]" in this/locals tree-tables
- Fixed "Go to Function" to highlight the target function in the source
window
- Synchronized ContextListener implementation
- Added slightly more useful tooltips to the tool bar
Note I modified files from today's rhinoTip.zip. Hopefully they were
identical to those in the cvs release branch.
Chris
Rhino: deal with all Throwables in Interpreter.interpret
Date:
Thu, 12 Jul 2001 14:27:34 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The attached patch modifies the catch code in Interpreter.interpret to
catch general Throwable exceptions to allow cleanup after throwing an
Error instance from Context.observeInstructionCount.
===================
Subject:
Rhino: change of InterpreterData.itsLineNumberTable from Hahstable to
UintHash
Date:
Thu, 12 Jul 2001 15:51:38 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The patch linetable_patch changes InterpreterData.itsLineNumberTable
from Hahstable to UintHash and debug/DebuggableScript.java to return
int[] array instead of Enumeration. It was run produced via
diff -ru javascript.0 javascript
The patch debugger_patch contains update for
toolsrc/org/mozilla/javascript/tools/debugger/Main.java to reflect above
api changes.
===============================
Subject:
Rhino: patch not to store VariableTable in InterpreterData
Date:
Thu, 12 Jul 2001 16:34:18 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The patch removes the "VariableTable itsVariableTable" field from
InterpreterData so it would not be stored in
InterpretedFunction/InterpretedScript and could be garbage collected
after interpreter byte code generation is finished. The usage of
theData.itsVariableTable it Interpreter.interpret is replaced by
accessing argNames/argCount fields from the passed NativeFunction.
Subject:
Fatal error executing in IBM J9 VM
Resent-Date:
Mon, 9 Jul 2001 15:35:32 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
9 Jul 2001 15:33:38 -0700
From:
bdemchak@tpsoft.com (Barry Demchak)
Organization:
http://groups.google.com/
To:
mozilla-jseng@mozilla.org
Newsgroups:
netscape.public.mozilla.jseng
Hi --
I've encountered an error in either Rhino or the IBM J9 VM's runtime
support -- I'm not sure which -- but the end result is an unhandled
exception. I'm quite willing to believe that it's already been dealt
with. If so, will someone point me to the solution?
I'm using: IBM's J9 on Windows 2000,
IBM's IDE v1.3 on Windows 2000,
Rhino v1.5 from mozilla.org
The exception is java.lang.StringIndexOutOfBoundsException.
It occurs in Context.getSourcePositionFromStack just after the call to
RuntimeException.printStackTrace. The code is expecting a code
reference that looks something like "(Example.js:50)" where "50" is
the line number. (I gather that's what the Sun VM returns???)
Instead, J9 is returning a code reference that looks like:
"java.lang.RuntimeException\n\n\n\nStack trace:\n\n
java/lang/Throwable.<int>()V\n\n" etc, etc, etc.
The error occurs because the Colon variable's value is less than the
Open variable's value in Context.getSourcePositionFromStack. When the
s.substring is evaulated, there's a negative string length ... boom.
I've patched an "if" statement in the getSourcePositionFromStack code
so that instead of:
if (c == '\n' && open != -1 && close != -1 && colon != -1)
I have:
if (c == '\n' && open != -1 && close != -1 && colon != -1 && open <
colon && colon < close)
Certainly, there's a better fix, but it's sufficient to keep me going.
So, I have several questions ... being new to open source and this
forum:
1) Is this a real bug ... a real Rhino bug??
2) Has this already been found?
3) Has this already been fixed?
4) If not, what's the proper protocol for reporting it?
5) What's the proper protocol for fixing it?
This shows up *very* quickly when trying to run a script under J9.
When it occurs, Rhino is trying to issue a warning about some shady
JavaScript code.
If this is a real bug and hasn't been fixed, I would infer that there
aren't a lot of people trying to run this under J9. Would that be a
fair statement? If so, can anyone comment as to why that would be??
Thanks!
Rhino: Fixes for catch in Interpreter.interpret
Date:
Wed, 11 Jul 2001 19:06:46 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
When doing that instruction counting implementation, I managed to mess
up code in the catch statement in Interpreter.interpret.
First for some reason I assumed that for a general RuntimeException the
previous code do not run finally statements but only script catch code.
Of cause this was wrong: that code skipped catch for arbitrary exception
while calling finally.
This is a reasonable behavior especially given the fact that arbitrary
RuntimeException may only arise from, say, bugs, other exceptions should
be wrapped to JavaScriptException.
Second I removed calls to debug.handleExceptionThrown...
The attached patch restores the original catch/finally logic and re-adds
calls to debug.handleExceptionThrown.
I will later update it that catch to handle Error as well to allow
cleanup after throwing an Error instance from
Context.observeInstructionCount , but restoration should go first.
Regards, Igor
Also, accept patches from Igor:
Subject:
Rhino: UintMap optimization
Date:
Fri, 06 Jul 2001 13:14:49 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
Currently omj.Node uses Hashtable to map int property types to
objects/integer. In my opinion this is very inefficient: to store single
int property it creates 5 objects: one for property Hahstable, 2 Integer
wrappers for property/value, array to sore Hahstable slots and Hashtable
slot itself. To fix this I added omj.UintMap class that can map
non-negative integers to objects or integers and modified omj.Node to
use it. The class is a hashtable implementation that uses one int[] and
one Object[] arrays to store keys/values and Object[] array is not
created if the map contains only integers.
To take full advantage of omj.UintMap code has to be modified to use
Node.getIntProp/Node.putIntProp to store int properties, but even in
this form it is a win.
I can provide patches to use Node.getIntProp/Node.putIntProp and UintMap
for InterpreterData.itsLineNumberTable if this is OK.
Regards, Igor
Mon, 02 Jul 2001 12:58:44 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
It turned out that in our browser implementation we need to be able to
abort too-long-running scripts. I implemented that for interpreter mode
via instruction counter callback. This callback is called at branch
points after instruction counter reach certain threshold as you
suggested once in mozilla-jseng mail list. The attached patch adds to
Context.java:
public int getInstructionObserverThreshold() {
return instructionThreshold;
}
public void setInstructionObserverThreshold(int threshold) {
instructionThreshold = threshold;
}
protected void observeInstructionCount(int instructionCount) {}
...
int instructionCount;
int instructionThreshold;
where observeInstructionCount is a callback that should be overwritten
in a custom Context to observe execution.
Then as long as instructionThreshold is not 0 modifications to
Interpreter.java increase instructionCount at branches/function
calls/catch blocks and call cx.observeInstructionCount when it reaches
instructionThreshold. I also replaces 3 catch statements in
Interpreter.interpret for EcmaError, JavaScriptException and
RuntimeException by single one to reduce code duplication.
The patch lacks documentation in Context.java but I would add that later
if the patch is ok.
Regards, Igor
==========================
Subject:
Re: Working for Rhino
Date:
Tue, 3 Jul 2001 10:41:42 +0200
From:
felix.meschberger@day.com
To:
Norris Boyd <nboyd@atg.com>
Hi Norris,
Well, I couldn't wait ;-) Here are my diffs :
LazilyLoadedCtor: Make class and constructor public for use on my host
objects
NodeTransformer : Replace checks for "arguments" by call to
checkActivationNeeded() in Context
Context: Add the name list proposed as a hashtable with
adder/checker/remover methods
Hope this helps. Regards
Felix
move debug object counters and various constructors to jsd_xpc.cpp
add LiveEphemeral struct to reperesent a link in a PRCList of ephemeral objects.
declare jsdIEphemeral interface in objects that need it, add invalidaAll static method to jsdIProperty and jsdIValue. jsdIObject still needs work.
Large changes to improve the way we deal with our wrappers around js engine structures. jsdIScript, jsdIStackFrame, jsdIValue, and jsdIProperty interfaces now inherit from a new interface "jsdIEphemeral". This interface is used to invalidate the wrapper. Once the wrapper is invalidated, *most* methods throw NS_ERROR_NOT_AVAILABLE, some interfaces, such as jsdIScript, cache important information so that the wrapper isn't utterly useless once it has been invalidated. The boolean isValid attribute can be used to see if the wrapper is still valid.
factor debug object counters into some simple macros
add new velid assertion macros for the new ephemeral objects
add utility functions for dealing with PR_CLISTs full of ephemeral objects.
invalidate the jsdIFrame after the execution hook completes
move some c/dtors from jsd_xpc.h over here to avoid exposing debug object counters, and repeating some macros
fix incorrectly set out parameter in getValue::GetDoubleValue
Subject:
Re: Rhino: [[DefaultValue]] missing for Call object
Resent-Date:
Mon, 2 Jul 2001 08:52:07 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
Mon, 02 Jul 2001 11:49:59 -0400
From:
Norris Boyd <nboyd@atg.com>
Organization:
Art Technology Group
To:
Christopher Oliver <coliver@mminternet.com>
CC:
mozilla-jseng@mozilla.org
References:
1
I believe the correct result of the script should be
[object global]
[object Object]
[object global]
The activation object (which goes by the name of "Call" for historical
reasons) should never be the 'this' value in a function call. See "10.1.6
Activation Object" in the ECMA spec.
I'll look at fixing the problem for Rhino. If there's agreement on my
analysis, someone should fix this for Spidermonkey too.
--N
Christopher Oliver wrote:
> Hi,
>
> function a() {
> function b() {
> print(this);
> }
> this.f = function() {
> print(this);
> b();
> }
> b();
> }
>
> var a = new a();
> a.f();
>
> Running the above script with SpiderMonkey produces:
>
> [object global]
> [object Object]
> [object Call]
>
> Running with Rhino produces the following exception:
>
> uncaught JavaScript exception: undefined: Cannot find default value for
> object. (line 3)
>
> This is due to a bug in org.mozilla.javascript.NativeCall which doesn't
> implement toString or valueOf or override getDefaultValue.
> However, even after I hacked in an implementation of getDefaultValue in
> NativeCall, Rhino still produces a different result then spidermonkey:
>
> [object Call]
> [object Object]
> [object Call]
Re: Bug in RhinoTip
Resent-Date:
Sat, 30 Jun 2001 11:45:38 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
Sat, 30 Jun 2001 20:54:21 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
nboyd@atg.com
CC:
Christopher Oliver <coliver@mminternet.com>, mozilla-jseng@mozilla.org
References:
1
Christopher Oliver wrote:
> Hi,
>
> I noticed the following in today's rhinoTip:
>
> js> throw 100
> js: uncaught JavaScript exception: java.lang.Object@5d601f
>
> js> throw 200
> js: uncaught JavaScript exception: java.lang.Object@5d601f
>
> js> throw i = 100
> js: uncaught JavaScript exception: 100
The attached patch to omj/Interpreter.java fixes that: I forgot to check
for stack[stackTop] == DBL_MARK during throw when implemented
interpreter optimization to minimize number of created Double instances.
I think that example should go to the test suite in a form like:
try { throw 100; } catch (ex) { return ex == 100; }
Regards, Igor
Bugfix to Rhino Debugger
Date:
Sat, 30 Jun 2001 06:09:44 -0700
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
nboyd@atg.com
Hi Norris,
Attached is a fix to a problem I encountered with the Rhino debugger.
Apparently some recent changes to the engine broke the debugger because
the debugger wasn't acquiring a Context before making certain engine
calls like ScriptableObject.getIds(). You can see this by stepping
through the "enum.js" example and expanding the variable "elements".
The below exception trace will be printed on the debugger console. The
attached file should fix this problem.
Chris
Subject:
Another fix to VariableModel.java
Date:
Sat, 30 Jun 2001 07:33:51 -0700
From:
Christopher Oliver <coliver@mminternet.com>
Organization:
Primary Interface LLC
To:
nboyd@atg.com
Hi Norris,
I modified this file to always call Context.toString() to display a
variable's value in the the tree table. Previously it only called it
for Scriptables and the toString() method of the object otherwise. This
caused for example JavaScript "2" to be displayed as "2.0".
Chris
This removes all call-sites I can currently fix. Tomorrow I'll try to get someone to checkin my changes to security/ and I'll get some help with the Netscape side of things.
nsString::GetUnicode()'s final death-blow will be dealt soon. Please keep this in mind as you add new code :-)
Rhino: speed optimization in omj/Interpreter.java
Date:
Tue, 26 Jun 2001 21:06:56 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
The attached Interpreter_patch contains a speed optimization patch that
tries to avoid creation of Double objects by keeping a parallel stack
for double values: instead of putting Double to the stack, DBL_MRK is
put and the real value is put to double stack (sDbl). Then when reading
stack with DBL_MRK, the double value from the double stack is used
wrapped to Double object when necessary. In addition local and vars
arrays are merged to stack array.
The attached before.txt and after.txt contain results of typical runs of
mozilla/js/benchmarks/all_bench.js before and after optimization on my
PC: Athlon 650/Red Hat 7.0/JDK 1.3.0 from Sun .
In number of cases the optimization actually slow down the executionby
5-10% (I guess due to the checks for DBL_MRK), but mostly it is a nice
sped up often by factor of 2 ot more with overall optimization win: 267
versus 218 seconds.
I guess it is possible to apply the same optimization to the optimizer
package, but in our browser we use strictly interpreter mode. Also by
changing signature of call/construct methods in Scriptable it is
possible to avoid creation of almost all objects currently allocated
during method calls, but that is for far future.
Regards, Igor
declare and initialize new provate members in jsdScript, copy important script properties at jsdScript creation time, so they're around after Invalidate().
large changes to fix the following bugs:
82684, crash manually clearing breakpoint
*actually* clearing mValid in jsdScript::Invalidate fixed this one.
85636, assertions on quiting venkman
jsdService::Off now disconnects the hooks into JSD, to avoid calling back into js after that. It also processes any pending script delete events that occurred during the last GC. The code to process the gPendingScripts list has been factored out of the gc callback. Processing the dead script list allows us to properly finalize all of the jsdIScript object, which seems to clear up the "gc roots exist at shutdown" assertions. In effect, these changes get rid of *all* of the jsd related assertions on exit.
Added isOn attribute to jsdIService.
Added isValid attribute to jsdIScript. We now prefetch appropriate properties from the underlying JSDScript, so that it's available after the script is Invalidate()d
moved jsdService constructor to jsd_xpc.h
Save the runtime passed to OnForRuntime so we can use it to clear the GC Gallback in Off().
