HI Erik I would love to try that. but like you said it requires a lot of time. I'm student (1 year of master of computer science) and I don't have time to do it. But, I think I have the solution for that : this semester, I can do a project, I can choose to have a project about that: I can get a Tutor (a teacher from my university), and maybe one or two students to work with me. We will try adding pseudo code support to v8 and produce open-source code. After the end of this semester, we could also extend the project to another semester. I have just move to my new university (TU-DARMSTADT, Germany), and the courses have not started yet. But they will start soon. So, you're ok with that, I have to start talking with thee teachers right now. In return,I think that maybe same stupid administrative things to do (and maybe not, I'm new in this university, and I'm not sure about how things works.) I think also someone, at google, has to answer our questions (this is exactly what your are already doing, so it's not a big deal). What do you think about that?
Cheers Riadh 2012/9/25 Erik Corry <[email protected]> > 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 > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
