Hi No problem Thank you anyway. 2012/9/26 Yang Guo <[email protected]>
> Hi Riadh, > > I'm afraid you can't expect any help from Google on the project you are > proposing. We don't think pseudo code support adds any value to V8 and > don't think that caching compiled code in V8 is possible. What you are > asking is continued support on this effort. Unfortunately, we cannot offer > that and certainly not to the extend of collaborating with your > university. Since V8 is open source, you are welcome to experiment on it by > yourself without our help. Thanks for understanding. > > Yang > > > On Tue, Sep 25, 2012 at 10:38 PM, riadh chtara <[email protected]>wrote: > >> 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 >> > > -- > 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
