Stopping javascript execution - a question and a feature request

[ohad.serfaty]

Hi All
I have been playing a lot with rhino lately , I have some questions
regarding script optimization

1. are there any stats as to how the optimizer reduces the runtime of
javascript ?

2. is it faster to compile a script that will be executed a lot of
times , and then exec the Script object ? is there any difference when
i use the -1 optimization ?

3. stopping the script in higher optimized code is impossible under
the current rhino conditions. I can use the Thread.stop() method but
am reluctant to do so as it is unsafe. Is it possible to have a stop()
or interrupt() function to stop execution of a malicious script thats
running in highly optimized context ?

Thanks in advance

[Norris Boyd]

On Sep 24, 9:11 pm, "ohad.serfaty" <ohad.serf...@gmail.com> wrote:
> Hi All
> I have been playing a lot with rhino lately , I have some questions
> regarding script optimization
>
> 1. are there any stats as to how the optimizer reduces the runtime of
> javascript ?

There's the JavaScript speed tests here: http://ejohn.org/apps/js-speed/results/.
I've modified them to run with Rhino interpreted as well, although I
haven't had the time to get accurate results and in a format to
report. For these kind of compute-intensive tasks, compiling to Java
bytecodes is a significant win. Not sure how typical a workload this
would be, however. I'd expect most Rhino applications to spend most
time in library routines or I/O.

>
> 2. is it faster to compile a script that will be executed a lot of
> times , and then exec the Script object ?

Yes, you then amortize the compilation costs across multiple script
executions.

> is there any difference when
> i use the -1 optimization ?

Yes, -1 means use Rhino's builtin interpreter. 0 and above mean
compile to Java classes.

>
> 3. stopping the script in higher optimized code is impossible under
> the current rhino conditions. I can use the Thread.stop() method but
> am reluctant to do so as it is unsafe. Is it possible to have a stop()
> or interrupt() function to stop execution of a malicious script thats
> running in highly optimized context ?

You're right that this is a feature request and a good one. The right
way to do this is to implement Context.observeInstructionCount for
compiled mode. There would need to be some way to indicate to the
compiler that you'd like to observe the count, and then compile in
callbacks from the generated Java classes at key points (backwards
jumps, function returns) that increment a counter by some value that
approximates the count of executed Java instructions. The runtime
could then monitor these like is already done for interpreted scripts.

I don't know when I'll get to this (patches accepted!), so in the
meantime I'd recommend using interpreted mode if this feature is
important to your application.

--Norris

>
> Thanks in advance

[ohad serfaty]

Hi Norris
Dived into your code. awesome job.
here is what i did to make this work ( at least partially...) , I added this
function to the CodeGen class :

private void addInstructionCount(int count){
cfw.addALoad(contextLocal);
cfw.addPush(count);
addScriptRuntimeInvoke("addInstructionCount",
"(Lorg/mozilla/javascript/Context;"
+"I)V");
}

And this function to the ScriptRuntime class :

public static void addInstructionCount(Context cx , int
instructionsToAdd)
{
cx.instructionCount += instructionsToAdd;
if (cx.instructionCount > cx.instructionThreshold)
{
cx.observeInstructionCount(cx.instructionCount);
cx.instructionCount = 0;
}
}

also , I have created an boolean field to the CompilerEnviros ( boolean
generateObserverCount ) that initializes itself from a similar field in The
Context class that. So in any place that i want to add an instruction count
in the generated class i will put this code :

(class CodeGen )

if (this.compilerEnv.generateObserverCount())
this.addInstructionCount(1);

Let me know if you think it will work out , plus , on which location in
CodeGen i should put this . also , I'd be happy to contribute in any way
that you think appropriate ( writing unit tests etc )

Cheers

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>

--
Ohad Serfaty

Dapper - http://www.dapper.net

[Norris Boyd]

Great, thanks for your work.

So we don't bother everyone else on the list, I created
https://bugzilla.mozilla.org/show_bug.cgi?id=397680. Please attach
your proposed changes as a diff to the bug and we'll continue our
conversation in the bug. If you add yourself as a cc on the bug you'll
get email notification.

And of course, people on the list can read and comment on the exchange
if they're interested.

--Norris

> > dev-tech-js-eng...@lists.mozilla.org