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).
git-svn-id: svn://10.0.0.236/trunk@116986 18797224-902f-48f8-a5cc-f745e15eee43
switch (...)
case LABEL:
code
to
switch (...)
case LABEL:
code
to has less problems with fitting to 80-character lines
git-svn-id: svn://10.0.0.236/trunk@116752 18797224-902f-48f8-a5cc-f745e15eee43
...
>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.
git-svn-id: svn://10.0.0.236/trunk@116729 18797224-902f-48f8-a5cc-f745e15eee43
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).
git-svn-id: svn://10.0.0.236/trunk@116725 18797224-902f-48f8-a5cc-f745e15eee43
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.
git-svn-id: svn://10.0.0.236/trunk@116633 18797224-902f-48f8-a5cc-f745e15eee43
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
git-svn-id: svn://10.0.0.236/trunk@116477 18797224-902f-48f8-a5cc-f745e15eee43
Use switch instead of string array to return token names not to depend on token oder.
git-svn-id: svn://10.0.0.236/trunk@116428 18797224-902f-48f8-a5cc-f745e15eee43
[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)
git-svn-id: svn://10.0.0.236/trunk@114372 18797224-902f-48f8-a5cc-f745e15eee43
* When turning debug generation on, don't change opt level from -1 to 0.
git-svn-id: svn://10.0.0.236/trunk@113903 18797224-902f-48f8-a5cc-f745e15eee43
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
git-svn-id: svn://10.0.0.236/trunk@112719 18797224-902f-48f8-a5cc-f745e15eee43
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
git-svn-id: svn://10.0.0.236/trunk@112485 18797224-902f-48f8-a5cc-f745e15eee43
