Locker, Preemption and TerminateExecution() method;

404 views
Skip to first unread message

Chinnu

unread,
May 6, 2011, 9:18:18 AM5/6/11
to v8-users
Hi,

I've been trying to implement a way to limit the execution time of a
script in V8. I've seen some previous posts that suggest using Locker
and Preemption (which effectively schedules the thread) and check for
timeout in the 'OnPreemtionReceived' method. If timeout exceeded,
invoke TerminateExecution().

However, invoking TerminateExecution() from within
'OnPreemptionReceived()' method is causing issues (I'm guessing it's
leaving the stack in an unbalanced state).

Is it wrong to invoke TerminateExecution() from within V8's code? Is
there a better way to implement the limiting of execution time?

Thank you,
Ravi

mcot

unread,
May 7, 2011, 10:26:34 AM5/7/11
to v8-users
Ok... so the problem with terminate execution is that it will
completely kill a given isolate (as far as I can tell). What I think
that means is that all local handles are destroyed and all persistant
handles are disposed. What I think you want (and also something I
want) is to be able to set a timeout for a single call to script-
>Run(). There is a subtle difference here. If your application calls
Run many times and is using a single isolate then we still have a
problem thats not solved by V8 (as far as I can tell).

Hopefully a V8 dev will come in here and explain this better and
hopefully offer a solution that I am not seeing. However, if we get
enough interest in this, I want to suggest a formal feature
enhancement to the V8 team to add a parameter to the Run function that
takes a timeout and maybe also a callback for when the timeout is
exceeded.

Here is the scenario I want to solve:

1.) My application is not threaded and it uses a single isolate.
2.) My application calls Run() many times. It does some work in C++,
calls Run() to run some JS supplied by a user, does some work in C++,
calls Run() ect...
3.) The JS supplied by the user could have infinite loops or long
running functions where the JS code is not calling into C++ (where I
could prevent them from running).

Mads Sig Ager

unread,
May 9, 2011, 1:54:03 AM5/9/11
to v8-u...@googlegroups.com
Could you create a reproduction of this issue and file a bug report?
Execution termination throws an exception that cannot be caught by
JavaScript. Control is returned to C++ activations (where the result
will be an empty handle) so that C++ can do cleanup before returning
to the calling JavaScript. When there is no more JavaScript frames on
the stack you can continue using V8. Something might have broken in
the termination support. If you can provide a stand-alone example
program that reproduces the issue we can investigate.

Thanks, -- Mads

> --
> v8-users mailing list
> v8-u...@googlegroups.com
> http://groups.google.com/group/v8-users
>

Chinnu

unread,
May 10, 2011, 3:50:22 PM5/10/11
to v8-users

Thank you for the replies.

The specific issue I'm trying to tackle is the one mentioned by mcot
above - running java script that could have infinite loops within it.

Currently, there is no way to come out of these infinitely running
scripts, which is understandable from a browser'd perspective (where
the user can chose to kill the browser window).

I do not have a simple code snippet to reproduce the issue with
TerminateExecution, but, will work on creating one. In the meantime,
if anyone has ideas on addressing the infinite loops in java script,
please let me know.

Thank you,
Ravi

Søren Gjesse

unread,
May 10, 2011, 5:11:13 PM5/10/11
to v8-u...@googlegroups.com
The V8 terminate execution should also handle JavaScript running in an infinite loop. The technique used is raising an internal stack overflow, and that will be caught in all loops as they should have a stack check on their back branch. In the V8 repository the tests in test/cctest/test-thread-termination.cc contains a number of tests including some with loops.

Maybe some of the stack checks are missing in optimized code. Have you tried to pass option --nocrankshaft?

Regards,
Søren
Reply all
Reply to author
Forward
0 new messages