No, there is no existing way to save and restore V8's state at arbitrary times. Sven has already explained why it's impossible to implement one. Assuming that V8 (or a Chrome renderer process) is single-threaded doesn't help, because it *isn't* single-threaded.
But even if what you're suggesting were possible, how would it help? Chances are, if you reset a given application to a state right before it crashed, it would just crash again, because the reason for the crash is already part of the application's state. A much more robust approach is to save relevant high-level state on the application layer, e.g. like GMail saves drafts on the server while you type. On Fri, Dec 20, 2013 at 10:10 AM, Venkatesh S <[email protected]> wrote: > if we turn of ASLR on the machine , is it possible to restore the state > and assuming that it is a single threaded application. > > > > On Tuesday, December 17, 2013 3:38:12 PM UTC+5:30, Venkata Savilla wrote: >> >> Thanks Sven . >> Is there any alternation ways of saving javascript context .Please >> suggest . >> >> Can we duplicate the render process to save document information. >> >> >> >> On Tuesday, 17 December 2013 14:58:58 UTC+5:30, Sven Panne wrote: >> >>> On Tue, Dec 17, 2013 at 10:10 AM, Venkata Savilla <[email protected]>wrote: >>> >>>> The use case is follows. >>>> >>>> when the users browses the website , some times browser crashes . >>>> I want to restore the application to the previous state by saving >>>> javascrpt context and DOM node data. >>>> i want to launch the webiste with the same state(previous to >>>> chrash) after the crash without hitting the webserver next time. >>>> >>> >>> So you want to restore a highly multi-threaded system to some given >>> state. Unless I'm totally missing something, this is fundamentally >>> impossible. When exactly do you want to save the state of the system? Note >>> that this will be a very heavy operation, subsystems have to be at some >>> kind of safe point, you will need to know what to save etc. etc. Even if >>> you manage to save the state, you will have a hard time restoring it, given >>> things like ASLR, multiple threads running etc. >>> >>> To be more specific about "safe points" for the v8 case: If you pick a >>> random point in time, you have no guarantee at all that it is even possible >>> to collect all necessary information. The heap might not be traversable at >>> that point, the stack not walkable, some locks might be held by some >>> threads, objects may be lying around half-initialized etc. Our snapshot >>> mechanism takes great care to get the VM into a very defined state before >>> it actually starts serializing the heap, furthermore there is no notion of >>> "currently executing JavaScript" then. >>> >> -- > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
