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().
xpconnect had been printing it's large "js component threw exception" whenever chatzilla's socket code threw NS_BASE_STREAM_WOULD_BLOCK from it's streamprovider (a non-error nsresult, bah.) This patch adds the exception to the "suppression list", to quiet the debug message.
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
>
Changes allow us to have a finer control over which parts of the tree are built with PIC. Part of the static build branch landing.
Bug #46775 r=mcafee a=leaf
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...
rginda%netscape.com
nboyd%atg.com
pschwartau%netscape.com
waterson%netscape.com
cls%seawood.org
jband%netscape.com
Xiaobin.Lu%eng.Sun.com
brendan%mozilla.org
valeski%netscape.com