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:
>>>
>>> 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
>
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
