1. This is a rather big undertaking and not trivial. You are free to take the V8 sources and add modifications to your liking, though. 2. V8 does not produce or run on byte code, but compiles Javascript to machine code directly and runs that. There is a of course a certain concern involved if the browser is to cache arbitrary executable code and run it. No big software project is free of bugs, and this approach would just add another attack vector.
Yang On Mon, Sep 24, 2012 at 9:43 PM, riadh chtara <[email protected]>wrote: > Hi Erik > Thanks for your answer > When I was reading it, I had two thought, the first one is stupid, the > second one is less stupid than the first one: > > 1. if I don't care about security(this the stupid part), and I want to > make a version of v8 that uses caches(when > 2. why does chrome (and other browser) save cache in RAW format, it > tooks time for v8 to parse js file, correct javascript syntax error... > After that work, I think it's better not to save the js file in cache, but > saving a byte-code file (some new format, which doesn't need to be parsed, > and could be easily read, without the need of doing the first step of > compilation). The byte code couldn't be run alone, and it needs v8 to > run. Thus, we don't generate a security isssues. I think we could do the > same thing for html and css. When we save them to cache, we can use a new > format that doesn't require parsing. > > What do you thing about that. > Cheers > Riadh > > 2012/9/23 Erik Corry <[email protected]> > >> This is a huge job, probably impossible: >> >> * Chrome has a sandboxing architecture that separates the renderers >> and the browsers. The renderer is the unsafe part of the browser that >> works on web-site provided data. This is where compilation of JS code >> takes place. The browser is what handles the caches. If you take >> compiled code from a renderer and put it in a cache then you are >> transporting data from an untrusted to a trusted part of the browser. >> And if you then give the compiled data to a different renderer you are >> violating the isolation of tabs. This would be OK if compiled data >> was in a simple, verifiable data format that could be checked for >> correctness, but as you say it's arbitrary machine code. >> * When the top level JS code runs (and creates 'classes', functions, >> etc.) it can do anything. It's JS code so it can change the intrinsic >> functions with monkey patching, it can make references to DOM objects >> (C++ heap allocated objects) and can make other changes to the native >> heap of the browser. Capturing all these changes in a serialized form >> that you can call 'the compiled code' is very difficult. Perhaps you >> can detect the presence of some changes and disallow serializations in >> some cases, but it's a non-trivial task, and if you get it wrong you >> have probably made a security issue of some sort. >> >> So it's not completely impossible. Objection number 2 does not apply >> to as large an extent to Dart, so perhaps in that language something >> is possible. Objection number 1 is perhaps something that extensive >> auditing, persuasion and hard work could fix. >> >> As for node.js I don't see the VM being started up so often in node.js >> applications so as far as I can see the compile time is not a big >> issue. I'm not sure there is a real issue to fix there. >> >> On Thu, Sep 20, 2012 at 11:47 PM, riadh chtara <[email protected]> >> wrote: >> > Hi >> > Javascript is today used in browser,server (node.js), mobile apps, >> firefox >> > os, webapps. and I really love it and I want to help making it better >> and >> > faster. >> > I think that one of the reasons that javascript is slow (despite the >> great >> > improvement done with modern engine such v8) , is that that javascript >> code >> > is compiled every time it used. >> > In v8, javascript is translated to machine code and then executed. And I >> > think it would be good idea to save generated code to reduce the time >> needed >> > for running javascript (in chrome for example, we save the generated >> files >> > instead of .js files) >> > If this new feature would be implement, v8 will gain a lot of speed, >> with >> > webapp, and website. >> > This enhancement will be also available for node.js. >> > what do you think about my idea? >> > And how much time do you think it would take to be done? >> > Cheers >> > Riadh >> > >> > -- >> > v8-dev mailing list >> > [email protected] >> > http://groups.google.com/group/v8-dev >> >> >> >> -- >> Erik Corry, Software Engineer >> Google Denmark ApS - Frederiksborggade 20B, 1 sal, >> 1360 København K - Denmark - CVR nr. 28 86 69 84 >> >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
