Compile v8 code, save in binary file and after then run stand alone or in c++ application.

[ionlupascu]

Hello all,
Is possible following variants:
1. Compile v8 code, save in binary file specific by os and platform
and after then run this binary file as a program.
2. Or compile v8 code by c++ application, save compiled data in file
or anywhere, load compiled code and after then run this code in this c+
+ application?

Thanks in advance.

[Dean McNamee]

I think it would be helpful to expand on what you're trying to
achieve. Is it about performance? Or just bundling your JavaScript
in a standalone executable?

[Søren Gjesse]

V8 supports "snapshots" where the V8 heap can be serialized and stored. A V8 instance can then be started right of this serialized heap. In Chromium this is used to reduce startup time. As parts of V8 is implemented in JavaScript time is spend in V8 startup compiling this builtin JavaScript which (together with other heap initialization) is avoided when starting V8 off a snapshot. The snapshot does not need to be taken just after normal initialization is done as is the case for Chromium (and V8 built using the snapshot=on option to the SCons build). It can be taken at any point in time e.g. after loading common JavaScript code used by a embedding application.

Note however that this is a "one shot operation" where the full heap is loaded from the snapshot there is currently no support in V8 for "partial" snapshots.

Regards,

Søren

[ionlupascu]

About performance is when I run same JavaScript code more than one
time, this save time on parsing source code and compilation process
(this process will be only one time). In this case I can save virtual
memory too, in complex systems, by loading only needed blocks of
compiled code.

About building JavaScript code in a standalone executables is very
excited variant. JavaScript language is very flexible and user
friendly that permit to programmers to mind on functional problems
realization but not on os-specification, type casting, memory
management or other technical problems. In this case we can achieve to
better programming quality.

I think that both variants would be helpful to expand.

Actual, My goal is to create an application that can integrate c/c++
interface plugins with JavaScript code. For the first I want to
automate accounting process but not limited on this.

Maybe it is realized and didn't found this? If yes, where can I found
a description or/and a simple example?

I tried to find a to do list of this project, but without success.

I'm ready to contribute.

[Stephan Beal]

On Thu, Aug 6, 2009 at 10:38 AM, ionlupascu <ionlu...@gmail.com> wrote:

About performance is when I run same JavaScript code more than one
time, this save time on parsing source code and compilation process
(this process will be only one time). In this case I can save virtual
memory too, in complex systems, by loading only needed blocks of
compiled code.

One of the big problems with this is that arbitrary code can have references to arbitrary OTHER code, and when you deserialize your code it is not generically possible to recreate any references which point to objects not defined directly in your code. e.g. if i serialize:

"v=8"

that can be serialized assuming "v" is a real object. However, during partial binary deserialization the old reference we saved now has no context/no meaning because "v" is not defined in our JS snippet and therefore we cannot re-build a reference to it in a pre-existing JS engine.

Partial deserialization/execution is, abstractly speaking, very similar to loading a DLL and executing it, and it's doubtful that JS will ever have such a feature natively (it's extremely insecure, for one thing).

 

Actual, My goal is to create an application that can integrate c/c++
interface plugins with JavaScript code. For the first I want to
automate accounting process but not limited on this.

Maybe it is realized and didn't found this? If yes, where can I found
a description or/and a simple example?

I tried to find a to do list of this project, but without success.

Several people on this list have created frameworks to assist in binding native code to JS. For example:

http://code.google.com/p/v8-juice/
http://code.google.com/p/cproxyv8/
http://code.google.com/p/v8cgi/

there are certainly others as well.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

[ionlupascu]

On Aug 6, 12:07 pm, Stephan Beal <sgb...@googlemail.com> wrote:

> On Thu, Aug 6, 2009 at 10:38 AM, ionlupascu <ionlupa...@gmail.com> wrote:
>
> > About performance is when I run same JavaScript code more than one
> > time, this save time on parsing source code and compilation process
> > (this process will be only one time). In this case I can save virtual
> > memory too, in complex systems, by loading only needed blocks of
> > compiled code.
>
> One of the big problems with this is that arbitrary code can have references
> to arbitrary OTHER code, and when you deserialize your code it is not
> generically possible to recreate any references which point to objects not
> defined directly in your code. e.g. if i serialize:
>
> "v=8"
>
> that can be serialized assuming "v" is a real object. However, during
> partial binary deserialization the old reference we saved now has no
> context/no meaning because "v" is not defined in our JS snippet and
> therefore we cannot re-build a reference to it in a pre-existing JS engine.
>

In that binary data need to save the header data which will include
functions and variables names and references. Another way, programmer
need manual manage with inter blocks parameters. in both case v8 need
save header data that describe functions and variables names and
references.

> Partial deserialization/execution is, abstractly speaking, very similar to
> loading a DLL and executing it, and it's doubtful that JS will ever have
> such a feature natively (it's extremely insecure, for one thing).
>

DLL have it own header data that describe global parameters, function
references and others.

> > Actual, My goal is to create an application that can integrate c/c++
> > interface plugins with JavaScript code. For the first I want to
> > automate accounting process but not limited on this.
>
> > Maybe it is realized and didn't found this? If yes, where can I found
> > a description or/and a simple example?
>
> > I tried to find a to do list of this project, but without success.
>
> Several people on this list have created frameworks to assist in binding
> native code to JS. For example:
>

> http://code.google.com/p/v8-juice/http://code.google.com/p/cproxyv8/http://code.google.com/p/v8cgi/

>
> there are certainly others as well.
>
> --
> ----- stephan bealhttp://wanderinghorse.net/home/stephan/

Thanks for suggest. this projects I already founded. Another project
is really interesting integration OpenGL with JavaScript.
Another suggestions?

[Stephan Beal]

On Thu, Aug 6, 2009 at 4:38 PM, ionlupascu <ionlu...@gmail.com> wrote:

On Aug 6, 12:07 pm, Stephan Beal <sgb...@googlemail.com> wrote:

> "v=8"
>

In that binary data need to save the header data which will include
functions and variables names and references. Another way, programmer
need manual manage with inter blocks parameters. in both case v8 need
save header data that describe functions and variables names and
references.

Right - but the only way to be sure to get ALL of it is to snapshot the WHOLE engine. v8 already does that. A JS engine *CANNOT* know exactly what code "v" references. What if we do:

v='name_of_a_function';

and we expect v to be eval-able with:

x=eval(v);
x(...);

the JS engine cannot know the meaning of v's value, and therefore cannot ensure at de/serialization time (without snapshotting everything) that the named function is in the VM. IMO, partial snapshotting for JS is essentially impossible to do correctly.

 

> Partial deserialization/execution is, abstractly speaking, very similar to
> loading a DLL and executing it, and it's doubtful that JS will ever have
> such a feature natively (it's extremely insecure, for one thing).
>

DLL have it own header data that describe global parameters, function
references and others.

And that's essentially what a serialized-to-binary JS snippet has to contain in order to be deserializable (serializing is easy, deserializing is not). Or all of the references need to be stored along with the serialized data. But then we're back to the problem that serializing this:

"v=3"

essentially needs to store the whole engine state. As a mental exercise, try to mentally DEserialize that, keeping in mind all of the context necessary in order to locate "v" and assign to it (and what if "v" isn't in the engine?). Serializing is normally easy, but deserializing never is: http://s11n.net/dream.php.

In any case, i'm personally of the opinion that partial snapshots to binary and back cannot be feasibly implemented in such a losely-typed language as JS, except in the very limited case of a small-scope runtime cache, where the referenced objects are guaranteed to still be alive in the VM, as opposed to long-term serialization, where the serialized references aren't guaranteed to be around at deserialization time.

[ionlupascu]

May be I'm not right, but you mean to store result of execution data
blocks(values of variables)? In header I mean to store only name of
functions/global variables, pointers of their execution, BUT NOT
VALUES. By manual initialization I mean that before user run a saved
binary block need himself initialized variable values. Transition
between blocks must be safety.

My questions are:
Is possible to realize this (store compiled code with possibility
restore, values initialization must set programmer)?
Is possible to compile an JS code and save in a stand alone execution
file?
V8 Compiled code is one binary code or is divided by objects and every
object have its own binary code?

Thank you Stephan for fast react.



On Aug 6, 6:03 pm, Stephan Beal <sgb...@googlemail.com> wrote:

[Stephan Beal]

On Fri, Aug 7, 2009 at 9:05 AM, ionlupascu <ionlu...@gmail.com> wrote:

May be I'm not right, but you mean to store result of execution data
blocks(values of variables)? In header I mean to store only name of
functions/global variables, pointers of their execution, BUT NOT
VALUES. By manual initialization I mean that before user run a saved
binary block need himself initialized variable values. Transition
between blocks must be safety.

But the names have no meaning in that context. Since such a blob could be run at arbitrary times, the names it references (and what about anonymous functions, without names?) may or may not have any relevance to the current engine state. Even if it is possible, it would require a mammoth effort and a few million Euros in programmer salaries.
 

My questions are:
Is possible to realize this (store compiled code with possibility
restore, values initialization must set programmer)?
Is possible to compile an JS code and save in a stand alone execution
file?
V8 Compiled code is one binary code or is divided by objects and every
object have its own binary code?

Thank you Stephan for fast react.

i unfortunately can't answer those last questions, except to vaguely comment:

- A compiled binary would require some form of runtime environment, so e.g. libv8 would have to be linked in. There was, at one point, lots of work going on to make Java exe files, but i think all of those attempts eventually died out because the exes were so huge and they had no benefits over .jar files.

- v8's engine builds up the binary code at runtime. Because of this, any serialization is platform- and bit-size dependent, and _possibly_ even dependent on what version of what compiler v8 was built with. So snapshotting it has little benefit outside of the immediate local application.

Having said all that - the v8 team has put a tremendous effort into speed optimization, primarily with the aim of producing the fastest browsers on the planet (Chrome and Android - i *assume* Android uses v8) for the next generation of rich web-based applications. If you're looking for scientific-supercomputing fast, don't use JavaScript. But if you just need "fast enough", JS is fine and v8 performs very well without the huge can of worms associated with partial snapshots.

:)

[ionlupascu]

On Aug 7, 10:19 am, Stephan Beal <sgb...@googlemail.com> wrote:

> On Fri, Aug 7, 2009 at 9:05 AM, ionlupascu <ionlupa...@gmail.com> wrote:
> > May be I'm not right, but you mean to store result of execution data
> > blocks(values of variables)? In header I mean to store only name of
> > functions/global variables, pointers of their execution, BUT NOT
> > VALUES. By manual initialization I mean that before user run a saved
> > binary block need himself initialized variable values. Transition
> > between blocks must be safety.
>
> But the names have no meaning in that context. Since such a blob could be
> run at arbitrary times, the names it references (and what about anonymous
> functions, without names?) may or may not have any relevance to the current
> engine state. Even if it is possible, it would require a mammoth effort and
> a few million Euros in programmer salaries.
>

About anonymous functions I think that is not need to add in header,
it uses only in intern runtime.

Very nice conclusion, Thank you!

Uses JS in my c++ applications is my dream, if I can have good
performance and flexibility.

[Stephan Beal]

On Thu, Aug 6, 2009 at 11:07 AM, Stephan Beal <sgb...@googlemail.com> wrote:

that can be serialized assuming "v" is a real object. However, during partial binary deserialization the old reference we saved now has no context/no meaning because "v" is not defined in our JS snippet and therefore we cannot re-build a reference to it in a pre-existing JS engine.

Not to beat a dead horse, but i've found a definitive reason why partial snapshotting *cannot* work generically: bindings to native objects. There is no way in the world that the deserializer could generically map those JS objects back to any bound native objects. e.g. a bound sqlite3 DB handle. The deserializer has no idea of (A) that the objects exists, (B) what they are, or (C) how to deserialize them (if it's even possible - transient types like db handles cannot be serialized in the first place).

[ionlupascu]

Ok,

I need to ask about building V8 code into stand-alone executable. Is
integrated this future in V8?

Thank you in advance.

On Aug 6, 1:04 am, Dean McNamee <de...@chromium.org> wrote: