[whatwg] Proposal for separating script downloads and execution

On Fri, Feb 11, 2011 at 5:12 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> I can grant you persisting information about the structure to some point
>> but generating byte code is not the job of the parser
>
> Well, the parser has to output _some_ representation.

>?In the case of
> Spidermonkey, the parser outputs bytecode directly. ?In the case of V8 it
> outputs an AST. ?Constructing those takes time.

in theory the parser could merely output for each function a start
point and an end point in a character stream representing the
functions.

i believe the only requirements for:

<script>
function x(){....}
function y(){....}
</script>

are:
1. if x fails to compile, y is not evaluated
2. y can fail to compile too
3. if something fails to compile, window.onerror is triggered
4. if x could compile, then window.x is defined to be a Function object
5. if x and y could compile, then window.y is defined to be a Function object
6. Function objects when accessed should behave as expected

in theory, i believe a js engine could choose to discard all work it
has done to validate syntax for x+y beyond saving those coordinates,
and then either do the proper ast / bytecode / machine code generation
lazily (or schedule to do it on a thread).

i'm not claiming that this would actually be better. i'm aware that to
determine if something compiles you have to generate roughly an AST. i
believe you could generate a simpler and more compact AST, as(you
probably can ignore variable decls and assignments once individual
statements are parsed. the tradeoff here is that you're allocating
less memory up front. once you've determined that x can compile, you
don't need to keep even the minimal AST for x.

> Oh, I agree that we shouldn't take current browser JS parser behavior as set
> in stone.

Received on Thursday, 10 February 2011 19:32:24 UTC