Hi Riadh We don't have plans to add pseudo code or byte code. The code is open source, so you are free to experiment.
On Tue, Sep 25, 2012 at 6:32 PM, riadh chtara <[email protected]> wrote: > Hi guys, > @yang guo > Thanks for your answser. > I already know that V8 doesn't support or produce byte code. > What I want to say is that it could be useful to implement a new pseudo code > support: > This an example of how I think chrome should work after the addition of > Pseudo code support: > When chrome want to run a .js file, he checks if it have the pseudo code for > it. If he dosn't found the pseudocode, he asks v8 to run it. V8 parses, > corrects errors and does whatever it has to be done with the .js file that > doesn't involve conversing to machine code and execution. At this point, v8 > has all data needed for easily generates a machine code file, so it creates > this file. This new file could be used instead of the original .js. It > doesn't need special treatment, before using it. And then if a page which > has the .js file was opened, when chrome checks the cache this time, he will > find the pseudocode, he will not load js file, he will only ask v8 to run > the pseudocode file. And because peseudo code file is almost ready (it > doesn't need to be parsed nor to be be checked for errors) , all what is > left for v8 to do is to convert the pseudo code to code and then run it. > > The same thing could be done for html and css files (i think that is the job > of chrome and not v8) : instead of saving these files to caches, it is > faster to save them i another new format. For html, we could use for example > this format : For each html tag we generate a code. And then the list of > codes is saved. > The code for a tag will contains these information > ID HTML-TAG-ID NEXT-SIBLING CHILD-COUNT FIRST-CHILD PROPERTIES-Count > PROPERTY-1-ID PROPERTY-1-VALUE PROPERTY-N-ID PROPERTY-N-VALUE > 32bit 16bits 16bits 32bits 32bits > 8bits 8bits (depend on propriety) > Example > for > <html> > <body bgcolor="red"> > </body> > </html> > Lets assume HTML-TAG-ID for html is 0, for body is 3 > Lets assume PROPERTY-1-ID for bgolor is 8 > the result file will be > 1 0 0 1 0 > 2 3 0 0 1 8 red > This file format for .html is not yet finished.But, the point I want to make > is that's very easy for a computer to understand this format. > So if chrome saves .html file in this format in it caches, the next time the > html file is open, it will be so easy and fast show it. > > I think the same thing applies also to css file, with of course another file > format suitlable for css stucture. > > > @Chen Yang > thanks also for your answer, > Could you tell me please about the snapshot feature of v8. > > Cheers > Riadh > > > 2012/9/25 Chen Yang <[email protected]> >> >> 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: >>>> >>>> if I don't care about security(this the stupid part), and I want to make >>>> a version of v8 that uses caches(when >>>> 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 > > > -- > 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
