I think recent Christopher suggestions about tail call elimination is worth
to consider, as it would allow to cut invocation cost of script functions
quite nicely in many cases. Plus I am thinking of not creating Object[] array
to pass arguments to callee if it is another interpreted function as it can
directly access the caller stack. But first I decided to make some
preparation work to simplify an implementation of these features later. The
attached patch includes:
1. Moving all code to setup scope from
InterpretedFunction.call/InterpretedFunction.call to Interpreter.interpret so
the call method simply calls Interpreter.interpret. It would make tail call
elimination code much simple. I also hope this simplifies changes Christopher
needs for the continuations support (but I have strong reservation about
possibility to implement it corectly).
2. Moving all declaration of temporary variables used only during processing
of the single ICODE to the case blocks.
3. Interpreter loop termination only in RETURN icodes, not when pc exceeds
icode size, so there is no need to check for this condition on each icode.
(Scripts are handled via the special END_ICODE token).
...
>I did some tinkering and found there are pure java.lang.Object
>instantiations deep inside all the "standard objects" added to the
>ImporterTopLevel with Context.initStandardObject(). This is what is keeping
>it from serializing.
This is due to presence of Scriptable.NOT_FOUND and IdScriptable.NULL_VALUE tags in the data to serialize.
I replaced the type for the tags from Object to UniqueTag which is serializable ad knows how to make restored tags the same objects as Scriptable.NOT_FOUND and IdScriptable.NULL_VALUE.
Similarly Undefined was made serializable and to restore to Undefined.instance upon reading.
While looking into optimizing the modifications I've
made, I noticed that one of the bottlenecks seemed to be calls to the Java
instanceof operator, particularly if the class argument to instanceof isn't
final. Based on this observation I tweaked ScriptRuntime.java to attempt to avoid
some of the many "instanceof Scriptable" calls in it (which I've attached). In
particular I optimized the comparison operators for the case where the arguments
are Number's. This seems to provide some significant performance improvement in
many cases particularly in compiled mode. See below (note the tests were
performed with today's rhinoLatest.zip code patched with the attached
ScriptRuntime.java and didn't include any of my other modifications).
2. ObjToIntMap.clear and UintMap.clear now do not discard internal buffers, but clears references to external objects to match behavior of Java Vector.clear and Hashtable.clear.
If I have a Java class with a normal method that throws an exception, Rhino
(1.5pre4) will let JavaScript catch the exception. If the Java class has a
getter method, Rhino will NOT let JavaScript catch the exception. Very
disturbing.
Here's a console dump to show you what I'm talking about:
D:\jsSandbox>cat GIJoe.java
public class GIJoe
{
// Getter
public static int getYoJoe()
throws Exception
{
throw new Exception("Please catch me!");
}
// Normal
public static int rebel()
throws Exception
{
throw new Exception("Please catch me too!");
}
}
D:\jsSandbox>javac GIJoe.java
D:\jsSandbox>cat gi.js
var gi = new Packages.GIJoe();
try
{
var i = gi.rebel();
java.lang.System.err.println("rebel(): uncaught");
}
catch(e1)
{
java.lang.System.err.println("rebel(): caught");
}
try
{
var i = gi.yoJoe;
java.lang.System.err.println("yoJoe: uncaught");
}
catch(e2)
{
java.lang.System.err.println("yoJoe: caught");
}
D:\jsSandbox>java -cp .;e:\javas\rhino1_5R4pre\js.jar
org.mozilla.javascript.too
ls.shell.Main
js> load("gi.js");
rebel(): caught
java.lang.Exception: Please catch me!
org.mozilla.javascript.WrappedException: WrappedException of Please catch
me!
at org.mozilla.javascript.JavaMembers.get(JavaMembers.java:105)
at
org.mozilla.javascript.NativeJavaObject.get(NativeJavaObject.java:93)
at
org.mozilla.javascript.ScriptRuntime.getProp(ScriptRuntime.java:691)
at
org.mozilla.javascript.Interpreter.interpret(Interpreter.java:1591)
at
org.mozilla.javascript.InterpretedScript.call(InterpretedScript.java:
63)
at
org.mozilla.javascript.InterpretedScript.exec(InterpretedScript.java:
54)
at org.mozilla.javascript.Context.evaluateReader(Context.java:741)
at
org.mozilla.javascript.tools.shell.Main.evaluateReader(Main.java:347)
at
org.mozilla.javascript.tools.shell.Main.processSource(Main.java:336)
at org.mozilla.javascript.tools.shell.Global.load(Global.java:169)
at java.lang.reflect.Method.invoke(Native Method)
at
org.mozilla.javascript.FunctionObject.callVarargs(FunctionObject.java
:586)
at
org.mozilla.javascript.FunctionObject.call(FunctionObject.java:460)
at
org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1216)
at
org.mozilla.javascript.Interpreter.interpret(Interpreter.java:1679)
at
org.mozilla.javascript.InterpretedScript.call(InterpretedScript.java:
63)
at
org.mozilla.javascript.InterpretedScript.exec(InterpretedScript.java:
54)
at org.mozilla.javascript.Context.evaluateReader(Context.java:741)
at
org.mozilla.javascript.tools.shell.Main.evaluateReader(Main.java:347)
at
org.mozilla.javascript.tools.shell.Main.processSource(Main.java:284)
at org.mozilla.javascript.tools.shell.Main.exec(Main.java:146)
at org.mozilla.javascript.tools.shell.Main.main(Main.java:74)
js>
Due to a lack of an "uncaught" statement in the output, we see that the
exception from GIJoe::getYoJoe() was indeed thrown, but not caught by the
JavaScript.
Do any nightly builds past 1.5pre4 address this issue?
Todd Trimmer
[javac] Compiling 1427 source files to /data/gump/xml-batik/classes
[javac] /data/gump/xml-batik/sources/org/apache/batik/script/rhino/EventTargetWrapper.java:81:
coerceType(java.lang.Class,java.lang.Object,boolean)
in org.mozilla.javascript.NativeJavaObject cannot be applied to
(java.lang.Class,java.lang.Object)
Thanks!
As promised, I tried the debugger this afternoon and I had a problem with the '-f' option.
We use -f to run a standard "startup" script before executing the "main" script. For
example, we run the Rhino shell with the options "-f startup.js main.js".
When running the debugger's shell with the same options the debugger exits after the
startup.js completes; i.e., I can single step starting from startup.js but the debugger
exits at the end of startup.js without letting me single step into main.js. This worked
fine in the 1.5R2 release of Rhino and the debugger.
I have not had a chance to look into the problem closely, but a cursory look at the code
suggests (to me) that the problem can be in either the debugger or the shell (since the
debugger basically runs the shell after creating the right "hooks".) Of course, it could
also be a problem with my embedding.
So ... my question is, has anyone tried single stepping when the options to the debugger
include a '-f' option. If so, I'll continue to look for a problem in my embedding.
Any suggestions would be appreciated.
Thanks,
dave
Norris,
I realize this is probably a nuisance, but the following problem causes our
regression test suite to fail:
js> foo = new Error("bar")
undefined: bar
js> foo.name Error
js> foo.toString()
undefined: bar
Our test suite expects:
js> foo = new Error("bar")
Error: bar
js> foo.name Error
js> foo.toString()
Error: bar
I have not yet tried the debugger with the RC2 release, but I expect to get
to that later today.
I hope I'm not to late to influence the 1.5R3 release.
Thanks,
dave
We have found a problem in string.replace() when replacing a regular
expression with a dollar sign. The following code works right when the
replacement string does not contain "$":
$ java -jar js.jar
js> var re = new RegExp("%%%");
js> var price = "%%% 1.99";
js> price.replace(re, "USD");
USD 1.99
js> price.replace(re, "$");
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException
at
org.mozilla.javascript.regexp.ReplaceData.interpretDollar(RegExpImpl.java:40 0)
at
org.mozilla.javascript.regexp.ReplaceData.findReplen(RegExpImpl.java:502)
at
org.mozilla.javascript.regexp.RegExpImpl.replace(RegExpImpl.java:116)
at
org.mozilla.javascript.NativeString.execMethod(NativeString.java:266)
at org.mozilla.javascript.IdFunction.call(IdFunction.java:78)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1222)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:1940)
at
org.mozilla.javascript.InterpretedScript.call(InterpretedScript.java:68)
at
org.mozilla.javascript.InterpretedScript.exec(InterpretedScript.java:59)
at org.mozilla.javascript.Context.evaluateReader(Context.java:773)
at
org.mozilla.javascript.tools.shell.Main.evaluateReader(Main.java:312)
at
org.mozilla.javascript.tools.shell.Main.processSource(Main.java:219)
at org.mozilla.javascript.tools.shell.Main.exec(Main.java:106)
at org.mozilla.javascript.tools.shell.Main.main(Main.java:68)
We are converting from spidermonkey to rhino and it appears that the
name property for the constructor function returns "constructor" for
all builtin types. Spidermonkey would return "Date" or "Array" or
whatever. Is there a workaround? This code needs to work with both
interpreters.
Here is an example of the rhino behavior:
js> var i=new Date;
js> i.constructor.name
constructor
js> Date.name
constructor
js> function bob(){}
js> bob.name
bob
js> var i = new Array();
js> i.constructor.name
constructor
js>
I'm the maintainer of JPackage project rhino package (see
jpackage.sourceforge.net). I just found two problems for building it (version
1.52 from cvs):
- the property src.debugger is badly initialised in toolsrc/build.xml. See
patch attached for correction. Moreover, this was a real pain to make offline
building possible. I guess it's a licensing problem that prevents you
including those files in rhino sources ?
- the produced javadoc has an empty (0 sized) package-list file. Have you got
any idea why ?
-- Guillaume Rousse <rousse@ccr.jussieu.fr>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
In our browser we need to support scripts that use as an identifier name future reserved keywords such as interface. The scripts are rather old and perfectly legal under previous revisions of EcmaScript which does not included the list of almost every Java keyword to the future reserve.
To support this I added an option to query Context.hasFeature for FEATURE_RESERVED_KEYWORD_AS_IDENTIFIER:
/**
* if hasFeature(RESERVED_KEYWORD_AS_IDENTIFIER) returns true,
* treat future reserved keyword (see Ecma-262, section 7.5.3) as ordinary
* identifiers but warn about this usage
*/
public static final int FEATURE_RESERVED_KEYWORD_AS_IDENTIFIER = 3;
The corresponding code in TokenStream checks for it and issues just a warning when this feature is enabled.
I also think that it would be better not to return RESERVED as a token from TokenStream.getToken but report the specific syntax error immediately because it is very unclear from the error message:
js> x.interface = 1
js: "<stdin>", line 1: uncaught JavaScript exception: SyntaxError: missing name after . operator (<stdin>; line 1)
js: x.interface = 1
js: ..........^
what exactly went wrong. I can send a patch later for that.
Regards, Igor
I'm working on a project which uses rhino. I wanted to have finer
control over class generation and saving so I've done some patching
and clean up on the current rhino tip.
The biggest change I've made is the replacement of ClassOutput with
ClassRepository that has the single method:
public boolean storeClass(String className, byte[] classBytes,
boolean isTopLevel) throws IOException;
This interface allows any arbitary storage method, such as a
Hashtable/Map. In addition it also allows you to specify whether a
class should be loaded, via returning true or false. You can still use
ClassOutput as I've coded an internal wrapper.
With this interface it has also been possible to strip out the file
saving code from Codegen and OptClassNameHelper. The file
saving code is now an inner class FileClassRepository in Context. As
a consequence of this I've stripped out some methods from ClassNameHelper.
The resulting code is much more cleaner then before hand and everything
still works as per usual.
Other small additions are:
o Annonymous functions are now named class$1 instead of class1
o get/setClassName added to ClassNameHelper exposed in Context.
My final thoughts are, since all methods in ClassNameHelper except reset()
are now exposed whould n't it be much more "cleaner" to simply to some
how work around to eliminate reset() and provide getClassNameHelper()
via Context? You could then remove the numerous ClassNameHelper shadow
methods from Context.
Likewise, FileClassRepository could be made a public class very easily
and combined with the above result in a dozen or so less public methods in
Context.
Anyway, the changes can be found on http://www.cins.co.uk/rhino.zip
Hope it is of use to some
Kemal Bayram
I'm working on a project which uses rhino. I wanted to have finer
control over class generation and saving so I've done some patching
and clean up on the current rhino tip.
The biggest change I've made is the replacement of ClassOutput with
ClassRepository that has the single method:
public boolean storeClass(String className, byte[] classBytes,
boolean isTopLevel) throws IOException;
This interface allows any arbitary storage method, such as a
Hashtable/Map. In addition it also allows you to specify whether a
class should be loaded, via returning true or false. You can still use
ClassOutput as I've coded an internal wrapper.
With this interface it has also been possible to strip out the file
saving code from Codegen and OptClassNameHelper. The file
saving code is now an inner class FileClassRepository in Context. As
a consequence of this I've stripped out some methods from ClassNameHelper.
The resulting code is much more cleaner then before hand and everything
still works as per usual.
Other small additions are:
o Annonymous functions are now named class$1 instead of class1
o get/setClassName added to ClassNameHelper exposed in Context.
My final thoughts are, since all methods in ClassNameHelper except reset()
are now exposed whould n't it be much more "cleaner" to simply to some
how work around to eliminate reset() and provide getClassNameHelper()
via Context? You could then remove the numerous ClassNameHelper shadow
methods from Context.
Likewise, FileClassRepository could be made a public class very easily
and combined with the above result in a dozen or so less public methods in
Context.
Anyway, the changes can be found on http://www.cins.co.uk/rhino.zip
Hope it is of use to some
Kemal Bayram <rhino@cins.co.uk>
I suggest to move the code in ScriptableObject.get/put that deals with getter/setter
into separated methods so it would be easy to follow the code and the attached patch
does just that.
The following test case case leads to a compilation error in Rhino. In this
script alert is an user defined
function in the global object and it shows the value of the specified
parameter in a popup window. Save the script as a html file and run it under
Netscape and IE. The output via their JS engines is that alert(1)
executes but the execution of line fails as blks variable is undefined. The
Fix bug:
Rhino engine fails at compilation time itself and cannot excute the script.
It doesn't like the syntax of line.
Steven
/// **************** test case ************** ///
<script>
alert(1);
blks[ 10 << 2 ] |= true;
alert(2);
</script>
/// ********************** Error Message ************************** ////
evaluating script: null
java.lang.NullPointerException
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICodeFromTree(Compiled Code)
at
org.mozilla.javascript.Interpreter.generateScriptICode(Interpreter.java)
at org.mozilla.javascript.Interpreter.compile(Interpreter.java)
at org.mozilla.javascript.Context.compile(Context.java)
at org.mozilla.javascript.Context.compile(Context.java)
I must admit this is very subtitle, but still...
Here are the lines from
public void defineProperty(String propertyName, Object delegateTo,
Method getter, Method setter, int attributes)
GetterSlot slot = (GetterSlot)getSlotToSet(propertyName,
propertyName.hashCode(),
true);
slot.delegateTo = delegateTo;
slot.getter = getter;
slot.setter = setter;
slot.setterReturnsValue = setter != null && setter.getReturnType() != Void.TYPE;
slot.value = null;
slot.attributes = (short) attributes;
slot.flags = (byte)flags;
Now suppose that after the new slot is added, another thread is accessing it. Then it would see not yet ready slot with all nasty consequences! For example, SMP computer can re-arrange writes so the new value of slot.flags would be visible before slot.getter then another thread would generate null pointer exception.
race2_fix.diff fixes that by using the explicit Slot argument to addSlot instead of boolean flag so the new slot can be fully initialized and then inserted under synchronization to the table. I also call addSlot directly because it is supposed to be used with not-yet existed properties and split addSlot to addSlot and addSlotImpl so in case of table growth there is no need to re-enter already synchronized monitor.
This changes also allows to explicitly throw RuntimeException if defineProperty is called for the property that is already exists instead of either throwing cast exception in "GetterSlot slot = (GetterSlot)getSlotToSet(propertyName," or worth yet re-initializing already existed slot.
Regards, Igor
Unsynchronized ScriptableObject.getSlotToSet contains references/modifications
to the slots array which is no go under multithreading. The attached patch
replaces references to slots by references to its local copy and moves code
to allocate the initial array to synchronized addSlot.
The patch also replace throwing of RuntimeException in case of broken code by
if (Context.check && badCondition) Context.codeBug();
Regards, Igor
also has a significant regression introduced in it. The default compiler
not only works, but also is noticably faster. Ant takes care of the
selection of the compiler automatically based on the JDK level, so the
following patch should make things better all around.
Patch from Igor:
The 2 attached patches allow to avoid wrapping of array indexes to Double object
when Interpreter knows that the index is an integer number. It speed up array
benchmark by 5-10%
array_access.diff adds to ScriptRuntime getStrIdElem and setStrIdElem to get/set
properties which known to be strings plus it modifies NativeArray to use these methods.
interpreter.diff contains the Interpreter modifications to call get/setElem for
integer or string properties when the property type is known for sure.
We have a tool that looks for a scary noop case of assigning an instance field
to itself. this usually comes from a constructor that assigns a argument to a
instance field with the same name and then later the argument changes name. we
ran our tool on all of our classes we have in our classpath here and found this
problem in your code.
rhino1_5R2/src/org/mozilla/javascript/regexp/NativeRegExp.java line 159 it has:
this.flags = flags;
This seems to be a bad cut and paste from the CompilerState constructor on line
2155. or has some initialization that used to work been lost?
There is a bug in JavaScriptException which prevents it from being used with
out a Rhino Context. When the getMessage() method is invoked on it, the
exception goes to the ScriptRuntime to toString the value. If you have
already exited your context, the runtime will throw an error. The solution
is to simply remove the overridden getMessage method from
JavaScriptException. JavaScriptException's constructor calls the Exception
constructor with the toString'ed value. The default implementation of
getMessage will return the exception message.
Jeff
I'm having problems getting inner class objects with Rhino.
I create a Hashmap, which is an implementation of Map. Map.Entry is an
inner interface of Map with key-value pairs. If I have a Map object,
"property", I should be able to get the key element with the expression
"property.key".
When I look at the "property" class name that Rhino returns I get:
"java.util.HashMap$Entry". I don't believe Rhino has a notion of the
inner Map.Entry object. The expression "property" succeeds. The
expression "property.key", which should retrieve the Map.Entry
keyValue(), fails with a "unexpected IllegalAccessException accessing
Java field".
I'm including a simple example that illustrates the problem. I hope you
can shed some light on this. Thanks!
Justyna
< Justyna.Horwat@Sun.com >
----
import java.io.*;
import java.util.*;
import org.mozilla.javascript.*;
public class MapTest {
public static void main(String argv[]) {
Test test = new Test();
test.testMap();
}
}
class Test {
Map map;
Set set;
Iterator it;
Map.Entry entry;
public void testMap() {
System.out.println("testMap");
map = new HashMap();
populate();
set = map.entrySet();
it = set.iterator();
// let's see if Map is populated correctly
while (it.hasNext()) {
entry = (Map.Entry) it.next();
System.out.println("entry: " + entry.getClass().getName());
System.out.println("key: " + entry.getKey());
System.out.println("value: " + entry.getValue());
}
evaluate();
}
void populate() {
map.put("firstKey", "firstValue");
map.put("secondKey", "secondValue");
map.put("thirdKey", "thirdValue");
map.put("fourthKey", "fourthValue");
}
public void evaluate() {
Context cx = Context.enter();
Scriptable scope = cx.initStandardObjects(null);
set = map.entrySet();
it = set.iterator();
while (it.hasNext()) {
entry = (Map.Entry) it.next();
scope.put("property", scope, cx.toObject(entry,scope));
}
Object eval = null;
try {
// attempt to get Map.Entry key value using Rhino
eval = cx.evaluateString(scope, "property.key", "", 0,
null);
// Unwrap scoped object
if (eval instanceof Wrapper)
eval = ((Wrapper) eval).unwrap();
} catch (JavaScriptException jse) {
System.out.println("EXCEPTION: " + jse.getMessage());
}
// DELETE
System.out.println("RHINO result: " + eval + ":");
System.out.println("RHINO class: " + eval.getClass().getName());
}
}
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.
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
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
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
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
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
I looked into this somewhat and I noticed the following:
1) There is a bug in Interpreter.java, line 1695. It sets the variable "i" to
the line number of the special call, but overwrites it on line 1699. It then
passes this value to ScriptRuntime.callSpecial
2) In "generateScriptICode" in Interpreter.java the variable
itsData.itsSourceFile fails to be set to itsSourceFile. This causes a null
source file name to be passed to handleCompilationDone when "Widget.js" is
compiled. That is why you
initially see "<stdin>, line 6" when the debugger comes up (the debugger
interprets a null source name as "stdin"). I simply modified it as follows
(this might not be the right thing to do?):
private InterpretedScript generateScriptICode(Context cx,
Scriptable scope,
Node tree,
Object securityDomain)
{
itsSourceFile = (String) tree.getProp(Node.SOURCENAME_PROP);
itsData.itsSourceFile = itsSourceFile;
...
and that corrected the problem.
However there seems to be no way for the debugger to detect that the script
passed to handleCompilationDone() is the argument of an "eval()". So I modifed
NativeGlobal.evalSpecial() to munge the filename to indicate this (by appending
"(eval)" to it). That way a separate window is created in the debugger to hold
the compiled eval code. This is probably not be the best way to solve the
problem.
I have attached the files I modified.
Cheers,
Chris
Simon Massey wrote:
> Christopher,
>
> Attached is the code that trips the debugger up. The debugger comes up. You
minimize the console to reveal Widget.js file window. You click 'Go'. The
Widget.js window looses all the code in it and is just replaced by the evaluated
code:
>
> this.invokedByEval()
>
> The rhino tip I have is rhino15R2pre.zip
>
> I am running it with the command:
>
> start javaw org.mozilla.javascript.tools.debugger.JSDebugger -f Widget.js -f
Main.js
>
> using the JVM:
>
> java version "1.3.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
> Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
>
> on Win2k.
>
> Just in case you are wondering why on earth my code wants to do this, it is
because I want to do some introspection. The real Widget invokes all its methods
that have a particular substring in their names:
>
> for( key in this ){
> if( key.indexOf('reflect') == 0 ){
> var evalStr = "this."+key+"()";
> eval(evalStr);
> }
> }
>
> Thanks for the great code. I have the real Widget stabilized and am happily
using the debugger on my other files.
>
> Thanks again!
>
> Simon Massey
>
jsdoc.js - added simple support for methods
Date:
Thu, 14 Jun 2001 09:12:26 +0100 (GMT Daylight Time)
From:
Simon Massey <simon_massey@hotmail.com>
To:
<nboyd@atg.com>
First off let me say thanks a lot for rhino. It is a really excellent piece
of software.
I am writing a large piece of js for making Excel2000 htm interactive on IE
and other browser such as Netscape6. Use a alot of code OO using methods
along the lines of:
/**
* Constructor
*/
function Type(x){
this.x = x;
}
/**
* Method
*/
Type.prototype.getX = function(){
return x;
}
var type = new Type('a');
var a = type.getX();
I have added to jsdoc.js so that finds and documents the method
declarations.
Attached is my modified jsdoc.js and a sample of the html that it generates
for the some of our proprietry :-( "Axel" code.
As an aside have you seen the job that www.blox.com have done on making a
dhtml spreadsheet? Bet they wished they could use exceptions in Netscape4!
Looking forward to the production JSDebugger. The tip version is great. It
does however seem to trash the view that it has of a file when an eval call
is made in that file. Is there a work around or will I have to wait till
the production version?
Thanks Again!
Simon Massey
-----
The patch adds to NativeArray.put a check for (this == start) so the
length field or a dense array element would not be updated if this !=
start. The following script exposes the problem:
function Test() { }
var array = new Array(0, 0); // Trigger dense mode
Test.prototype = array;
var test = new Test();
array[0] = 1;
test[0] = 2;
print(array[0]); // Should print 1, not 2
-----
When initially I switched NativeDate to use IdScritable, I made
toGMTString just an alias to toUTCString. Later I realized that it could
cause troubles if someone would check Date.prototype.toGMTString.name to
get "toUTCString" so I made the code to allocate a separated IdFunction
to toUTCString. Now when I read ecma 3 appendixes I see that the initial
behavior is what actually Ecma 3 requires. Here is an extract from B.2.6:
The Function object that is the initial value of
Date.prototype.toGMTString is the same Function
object that is the initial value of Date.prototype.toUTCString.
Sometimes doing nothing is the best solution...
The attached patch fixes that and inlines many 1-3 lines functions as
optimization that java compilers typically do not want to do...
1. Keyword search via Java Hahstable is replaced by explicit "switch"
code generated by idswitch tool. It not only speed up keyword search and
eliminates all Integer objects created to hold keyword tokens and
corresponding Hahstable structures, but it also reduces code size due to
very poor array initialization support in JVM.
2. It replaces the isXDigit method by xDigitToInt that either converts
its argument to 0..15 or returns -1 if it is not a hex digit and updates
the method usage accordingly The patch updates NativeGlobal.js_unescape
to reflect this usage change.
In the attached patch I added documentation, did some inlining in the
get method implementation to gain some speed and overrode defineProperty
so it plays better with id-based properties.
-----
The patch fixes a bug in getIds method where the assignment "result =
tmp" was missed, adds the public method activateIdMap(int maxId) to
IdScriptable and changes setAttributes method not to allow setting of
attributes that are less restrictive then ones returned by
getIdDefaultAttributes. That was supposed to be the case and the patch
makes it explicit.
-----
The patch makes BaseFunction.setImmunePrototypeProperty public so it can
be called from other packages (regexp).
-----
The patch switches NativeRegExp and NativeRegExpCtor to use
IdScriptable. It also changes code in a few places to passes Context and
RegExpImpl directly instead of using Context.getCurrentContext().
The patch also fixes a bug when
for (var i in RegExp) { print(i); }
would not include $1..$9 in the output in violation with Ecma. It was
caused by not overriding ScriptableObject.getIds in
NativeRegExpCtor.
-----
The patch changes NativeCall to use IdScriptable. This is done mostly
for uniformity with other Native* classes plus it would allow to call
NativeCall.init directly and make NativeCall package private.
-----
The patch changes NativeScript to use id-based properties. Due to
inheritance from NativeFunction, id support requires to take into
account the fact that there are instance ids available from
BaseFunction. This is the reason to use "int prototypeIdShift" instead
of "boolean prototypeFlag" so it can store instance id offset.
The patch updates ScriptRuntime.callOrNewSpecial to check against
IdFunction and not FunctionObject for the Script exec method where it
also add finally clause to make sure that Context.exit would always be
called after Context.enter in the evalScript method.
-----
After converting NativeScript and NativeFunction to use IdScriptable,
they get scope argument directly as a parameter of execMethod call, so
cx.ctorScope is not used any more. The patch removes code to set/unset
cx.ctorScope.
-----
[This patch depends on conversion of NativeScript and NativeCall to use
IdScriptable and the patch to remove access of ctorScope from
FunctionObject]
The patch changes Context.initStandardObjects to call NativeCall.init
and NativeScript.init directly plus it unrolls the lazily initialization
loop. Due to rather poor support of an array initialization in Java byte
code, it actually decreases code size while eliminating are creation of
array object. The patch also removes ctorScope field as unused.
-----
The patch makes sure that ids used by NativeGlobal are visible only in
the object instance that initializes global scope and removes some junk
white space at line ends.
-----
To use the idswitch tool to generate map for strings that can not be
part of Id_ Java identifier like $*, I added code to the tool to look
for "// #string=...#" in the id definition line. The attached README
file also contains some documentation about the tool and should go to
idswitch directory.
The patch was made from toolsrc/org/mozilla/javascript/tools via:
cvs diff -u > idswitch_patch
----
The patch changes Notification to extend from BaseFunction and adjusts
Context, FunctionObject and NativeScript accordingly.
----
The patch changes BaseFunction.jsConstructor to use the scope argument
passed to execMethod instead of using cx.ctorScope. This argument is
null in this case because when calling execMethod IdFunction.construct
does not set cx.ctorScope because scope is passed to execMethod as argument.
for classes implementing the Function interface and switch
IdFunction.java to use it. The code in BaseFunction to serve as
Function.prototype is not used yet. The patch modifies NativeCall so it
can be used against BaseFunction.
The patch was made from org/mozilla directory via
diff -uN javascript.0 javascript > BaseFunction_patch
in fields of the object itself instead of using the standard property
hashtable in ScriptableObject.java. This saves 3 object instances per
NativeError (2 slot entries and hashtable array itself) and given the
fact that NativeGlobal defines a few permanent Error instances, it is
visible saving even after taking into account code size increase.
The change also gives a good test of IdScriptable implementation.
-----
This patch introduces the uniform decompile method for NativeFunction
and IdFunction with the signature:
public String decompile(Context cx, int indent, boolean justbody)
instead of NativeFunction.decompile(int indent, boolean toplevel,
boolean justbody) and IdScriptable.toStringForScript(Context cx) and
replaces the special treatment of NativeJavaMethod in
NativeFunction.jsFunction_toString by overriding decompile in
NativeJavaMethod
-----
This patch adds getFunctionName to NativeFunction to return function
name and replaces few places with jsGet_name usage by getFunctionName
The patch was made via
diff -ru javascript.0 javascript > name_patch
from org/mozilla directory
Rhino: behavior update for IdScriptable subclasses
Date:
Fri, 18 May 2001 11:45:00 +0200
From:
Igor Bukanov <igor.bukanov@windriver.com>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The attached patch introduces separation between id-base properties in
prototype instances and the rest of objects so it is possible to
allocate some ids for each instance and the rest only for prototype. The
patch adds to each descendants of IdScriptable a special prototypeFlag
which set to true only if object serves as a global prototype and all
methods that check/return ids first check for that flag. (This is the
reason for the patch size: diff is not very well in dealing with
indentation changes.)
In this way ids for prototype properties are completely hidden from
potential subclasses and there is no need to define methods like
getMaximumId in most cases, only if some ids present in each instance,
IdScriptable.maxInstanceId should be overridden to return max id present
in each instance.
The patch also replaces 2 boolean fields in IdScriptable by bit masks in
the setupFlag field.
Subject:
Embedding Rhino in an Applet
Resent-Date:
Thu, 17 May 2001 14:53:05 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
Thu, 17 May 2001 16:39:14 -0700
From:
"Chester Kustarz II" <chester@monkey.org>
Organization:
monkey.org
To:
mozilla-jseng@mozilla.org
Newsgroups:
netscape.public.mozilla.jseng
Hello, I am trying to find a scripting language with an interpreter that I
can embed in an applet in order to run test scripts inside the applet. I
have already tried TCL-based Jacl and they do not support running inside an
applet. I then downloaded the Rhino/JS interpreter but am having trouble
getting it to run inside the browser (IE 5.5). Here is the exception I am
getting:
com.ms.security.SecurityExceptionEx[org/mozilla/javascript/ScriptRuntime.<cl
init>]: Reflective access to class java.lang.Thread prohibited.
at com/ms/security/permissions/ReflectionPermission.check
at com/ms/security/PolicyEngine.deepCheck
at com/ms/security/PolicyEngine.checkPermission
at com/ms/security/StandardSecurityManager.chk
at com/ms/security/StandardSecurityManager.checkMemberAccess
at java/lang/Class.checkMemberAccess
at java/lang/Class.getDeclaredMethod
at org/mozilla/javascript/ScriptRuntime.<clinit>
at org/mozilla/javascript/ScriptableObject.getExclusionList
at org/mozilla/javascript/ScriptableObject.defineClass
at org/mozilla/javascript/Context.initStandardObjects
at org/mozilla/javascript/Context.initStandardObjects
at RhinoShellApplet.init
at com/ms/applet/AppletPanel.securedCall0
at com/ms/applet/AppletPanel.securedCall
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.run
at java/lang/Thread.run
com.ms.security.SecurityExceptionEx[org/mozilla/javascript/Context.initStand
ardObjects]: Unable to access system property:
org.mozilla.javascript.JavaAdapter
at com/ms/security/permissions/PropertyPermission.check
at com/ms/security/PolicyEngine.shallowCheck
at com/ms/security/PolicyEngine.checkCallersPermission
at com/ms/security/StandardSecurityManager.chk
at com/ms/security/StandardSecurityManager.checkPropertyAccess
at java/lang/System.getProperty
at org/mozilla/javascript/Context.initStandardObjects
at org/mozilla/javascript/Context.initStandardObjects
at RhinoShellApplet.init
at com/ms/applet/AppletPanel.securedCall0
at com/ms/applet/AppletPanel.securedCall
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.run
at java/lang/Thread.run
1. In that patch I forgot to remove "import org.mozilla.classfile.*" and
simply catch Exception in newInvokerMaster which is not a good practice.
The attached patch FunctionObject_patch fixes that and removes other
unused imports.
2. In org.mozilla.classfile.DefiningClassLoader defineClass method first
tries to call via ClassManager the defineClass method in a class loader
that loaded DefiningClassLoader itself. But this would define new
classes in that class loader so they would not be subject of the garbage
collection until a classloader that loads DefiningClassLoader would go
away even if a DefiningClassLoader instance is gone. The
DefiningClassLoader_patch removes that and simply calls super.defineClass.
The patch also change the order of class search in loadClass so the
loader first looks for a class among its defined classes and only after
that in parent loaders.
Regards, Igor
1. In that patch I forgot to remove "import org.mozilla.classfile.*" and
simply catch Exception in newInvokerMaster which is not a good practice.
The attached patch FunctionObject_patch fixes that and removes other
unused imports.
2. In org.mozilla.classfile.DefiningClassLoader defineClass method first
tries to call via ClassManager the defineClass method in a class loader
that loaded DefiningClassLoader itself. But this would define new
classes in that class loader so they would not be subject of the garbage
collection until a classloader that loads DefiningClassLoader would go
away even if a DefiningClassLoader instance is gone. The
DefiningClassLoader_patch removes that and simply calls super.defineClass.
The patch also change the order of class search in loadClass so the
loader first looks for a class among its defined classes and only after
that in parent loaders.
Regards, Igor
> Igor Bukanov wrote:
>
>
>>Norris Boyd wrote:
>>
>>
>>>The intention was to keep classfile and JavaAdapter optional. Those
>>>dependencies crept in. We can use Invoker optionally--perhaps I should do
>>>some performance numbers to see if it's worth it.
>>>
>>I implemented that patch, it splits Invoker.java into Invoker.java and
>>its implementation in optimizer/InvokerImpl.java The reason to put it
>>into optimizer package is that Invoker is very similar in spirit to
>>NativeScript: it generates classes to speed up access and in this way
>>there is no need to have separated option not to use: one can simply
>>remove optimizer all together.
>>
>
> Yes, that sounds great.
>
>
>>
>>I noticed during implementation that JavaAdapter.DefiningClassLoader and
>>optimizer/JavaScriptClassLoader contains the same code, so maybe they
>>can be moved to org.mozilla.classfile package under one name?
>>
>
> Yes, that sounds like a good change too. Thanks for noticing that.
The update is pretty messy: it touches FunctionObject which I changed to
remove the special treatment of NativeWith in the previous patch, and it
also add/removes files.
Here is a description:
DefiningClassLoader.java should go to org/mozilla/classfile. It is the
same code that was in omj/optimizer/JavaScriptClassLoader.java with
class rename and adding public attribute and correspondingly
omj.optimizer/JavaScriptClassLoader.java should be removed. I guess it
would be nice to preserve logs/history in CVS during the move.
InvokerImpl.java should go to omj/optimizer. It is mostly what
omj.Invoker was.
invoker_changes_patch was generated via
cvs diff -u Invoker.java JavaAdapter.java optimizer/Codegen.java
and contains changes against the current CVS
FunctionObject_invoker_patch was generated via
diff -u ../../mozilla.1/javascript/FunctionObject.java FunctionObject.java
and contains changes against that With patch.
Igor
constructor, removes the special treatment of the With object from
IdScriptable and FunctionObject, adds to IdFunction the
initAsConstructor method similar in spirit to
FunctionObject.addAsConstructor (it is called now from IdScriptable and
NativeWith) and replaces in Context.java lazy initialization of
NativeWith by direct call of NativeWith.scopeInit.
The attached patch moves the IdFunction.Master interface to the
separated file IdFunctionMaster and eliminates getParentScope from the
interface: it is simpler to set scope explicitly.
The patch assumes the changes in IdFunction.java from the previous patch
and were produced via:
diff -uP javascript.2000-05-10 javascript
Regards, Igor
The attached patch allows subclasses of IdScriptable to override
hasIdValur/deleteIdValue and uses lazy initialization for idMapData
array to avoid its creation when an IdScriptable descendant does not
have any functions. The patch also touches NativeMath.java to replace in
its scopeInit method
super.scopeInit(cx, scope, sealed);
by
activateIdMap(cx, sealed);
This is the only reason NativeMath needs to call
IdScriptable.scopeInit() which is intended for creation
constructor/prototype pair.
Regards, Igor
Rhino: optimization for NativeFunction.java
Date:
Mon, 07 May 2001 14:19:59 +0200
From:
Igor Bukanov <igor.bukanov@windriver.com>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
This is the first of 3 patches that are completly independent from each
other.
Currently in NativeFunction its name stored as the first element in the
names array. But this lead to creation of a single element array for
each FunctionObject and for each script function that does not have
arguments or variables. The attached patch splits NativeFunction names
into simple functionName and argNames arrays and adjust code elsewhere
accordingly. This patch can increase memory footprint for anonymous
script functions without arguments because it adds additional field to
each NativeFunction, but I do not think this is a case to worry about.
Regards, Igor
Date: Mon, 07 May 2001 14:25:34 +0200
From: Igor Bukanov <igor.bukanov@windriver.com>
Organization: Wind River
To: Norris Boyd <nboyd@atg.com>
The current code that implements execMethod/methodArity for IdFunction
support returns an arbitrary value for id that is not known. This is not
very good behavior because it may hide bugs in the id support and it
also does not allow to distinguish ids that are used for function from
ids used for properties like String.length.
To fix this I changed semantic of the methodArity method to return -1
for an unknown/non-method id and added code to throw an exception for
bad ids. This change requires to adjust all NativeSomething objects that
use IdScriptabl and after a release all such interface changes would be
no go, but is not a release yet, right?
I also eliminated the "IdFunction f" argument from
IdFunction.Master.methodArity and the tagId field from IdFunction. When
I wrote the initial code for IdFunction.java, I added that just to be
able to use same id number in a class that implements IdFunction.Master
and its descendants via checking idTag. But that does not work in
general because IdScriptable can use id for non-function fields as well
so to avoid id clashes another way should be used. For example, if
someone would like to extend NativeMath to support more functionality,
he can use:
class Math2: extends NativeMath {
private static idBase;
{
if (idBase == 0) idBase = super.getMaximumId();
}
public int methodArity(int methodId) {
switch (methodId - idBase) {
case Id_foo: return 2;
case Id_bar: return 3;
}
return super.methodArity(methodId);
}
public Object execMethod
(int methodId, IdFunction f,
Context cx, Scriptable scope, Scriptable thisObj, Object[] args)
throws JavaScriptException
{
switch (methodId - idBase) {
case Id_foo: return ...;
case Id_bar: return ...;
}
return super.execMethod(methodId, f, cx, scope, thisObj, args);
}
protected int getMaximumId() { return idBase + MAX_ID; }
protected String getIdName(int id) {
switch (id - idBase) {
case Id_foo: return "for";
case Id_bar: return "bar";
}
return super.getIdName(id);
}
...
private static final int
Id_foo = 1,
Id_bar = 2,
MAX_ID = 2;
etc.
Note that a simpler solution to make MAX_ID field public in NativeMath
and write in Math2:
private static final int
Id_foo = NativeMath.MAX_ID + 1,
Id_bar = NativeMath.MAX_ID + 2,
MAX_ID = NativeMath.MAX_ID + 2;
does not work because in this way adding any new id to NativeMath would
break binary compatibility with Math2.
Rhino: fix for race conditions in listeners code in Context.java
Date:
Mon, 07 May 2001 14:22:57 +0200
From:
Igor Bukanov <igor.bukanov@windriver.com>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
The current code for listeners and contextListeners in Context.java is
not race condition free. If contextListeners Vector would be modified
during context event firing loops, the code can produce
index-out-of-bounds exception. The problem with listeners array is more
subbtle and comes from the fact that ListenerCollection.java uses code like:
for(Enumeration enum = getAllListeners();enum.hasMoreElements();) {
Object listener = enum.nextElement();
if(iface.isInstance(listener)) {
array.addElement(listener);
}
}
where getAllListeners() uses Vector.elements to get element enumeration.
But to work with such enumeration in a thread safe way, one has to
synchronized against Vector, otherwise between enum.hasMoreElements()
and enum.nextElement() the last element can be removed.
Initially I thought to fix ListenerCollection and use it for
contextListeners as well, but then I realized that in its current form
ListenerCollection is very inefficient (it produces too many objects
just to get simple array to fire events), so I wrote ListenerArray.java
and use it in Context.java. It makes life simpler and shrinks code as well.
Subject:
rhino bug(s)
Date:
Mon, 30 Apr 2001 23:07:00 -0700
From:
Mike Dixon <MDixon@placeware.com>
To:
nboyd@atg.com
hi. i'm a happy rhino user, and just stumbled across what looks like a
pretty basic bug in the property stuff on ScriptableObject... (i'm running
1.5, but it looks like this code hasn't changed in CVS.) since it looks
like you're actively developing (even though it's been a while since
1.5...) i figured you might be interested -- apologies if i missed a more
formal bug reporting process...
the symptom was that i got a "Hashtable internal error" thrown from
getSlotToSet. reading the code, here's what i think could happen:
- create a new object (slots.length is initially 5)
- add 3 properties
- delete those 3 properties
(now count == 0, and slots[i] == REMOVED for 3 values of i)
- add 2 more properties
now assume that you're unlucky, and that these two hash to different values
than the first three; now you have 2 elements of slots[] containing real
slots, and the other three containing REMOVED.
now what happens when you try to create another slot? getSlotToSet is only
willing to put something in a null slot[], and you haven't got one, so you
get the internal error.
writing this message encouraged me to try to write a test case to reproduce
it, and in fact it's trivial:
js> x={}; x.a=x.b=x.c=1; delete x.a; delete x.b; delete x.c; x.d=x.e=1
1
js> x.whatever=1
(boom)
by the way, while reading the code i also noticed what looks like another,
less consequential bug: addSlot increments count before deciding to grow
the table, which is done with a recursive call, which will cause count to
be incremented again -- right? as far as i can tell, setting count too big
will only cause it to grow the table a little early next time, so it
doesn't really matter, but it looks wrong.
.mike.
