Thanks for lots of insights shared from the discussion. Will it be feasible to extend the feature of snapshot in current v8 to provide the functionality? Thanks. -- Chen
On Tue, Sep 25, 2012 at 2:17 PM, Yang Guo <[email protected]> wrote: > 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 > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
