Add comments about lazy parsing and lazy compilation.

Add comments about lazy parsing and lazy compilation.

Also rename is_lazily_compiled in (Pre)Parser; it really means "is lazily
parsed" and doesn't correspond to the lazy compilation decision.

R=svenpanne@chromium.org
BUG=

Committed: https://code.google.com/p/v8/source/detail?r=19492

[marja, 2014-02-19 09:28:30]

svenpanne, ptal

[Sven Panne, 2014-02-19 09:51:10]

LGTM, but it would be great if you could figure out one more detail and comment
it...

https://codereview.chromium.org/169223009/diff/30001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/169223009/diff/30001/src/parser.cc#newcode4038
src/parser.cc:4038: is_lazily_parsed = false;
Mind explosion... o_O Can we add a comment here, too? I don't have the slightest
clue why we set this to false here...

[marja, 2014-02-19 12:19:47]

thx for pointing out the hairy line of code... it was ofc even hairier than i
thought when i started digging :/

https://codereview.chromium.org/169223009/diff/30001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/169223009/diff/30001/src/parser.cc#newcode4038
src/parser.cc:4038: is_lazily_parsed = false;
On 2014/02/19 09:51:11, Sven Panne wrote:
> Mind explosion... o_O Can we add a comment here, too? I don't have the
slightest
> clue why we set this to false here...

This is just an error case, where we do have preparse data but fail to get
information for this particular function from it. So this is a safety net to
bail out and parse eagerly in that case. I think it's not important that we
parse eagerly, but we might as well do the "else" branch below ("partially parse
the function without building the AST") in that error case. I don't think
there's any deeper wisdom here. But ofc I cannot be 100 % sure since I didn't
write the code and there is no comment.. ;)

There *used* to be a comment in this branch but it was removed by
https://codereview.chromium.org/8662037/diff/11001/src/parser.cc . The comment
was: "There is no preparser data for the function, we will not lazily compile
after all.", but if that's true, it's pretty bad. That would mean PreParser
knows something about lazy compilation that Parser doesn't and that's just wrong
(Parser should always be the more clever one).

Another piece of code archaeology: https://codereview.chromium.org/7565003 added
the original logic, and this CL actually claims that 1) PreParser and Parser
*might* do the lazy analysis differently (huh?) 2) PreParser should be regarded
as an authority if they differ (why on earth?) and 3) if PreParser thinks
something is lazy, and Parser think it's not, all further laziness will fail
since we never advance the preparse data. (This is true.)

Okay, now my mind is blown, too. o.O If even the code authors are unsure whether
the PreParser laziness analysis and Parser laziness analysis can produce
different results, and only one of the 2 directions is handled properly, it's
pretty bad.

Anyhow, I added a comment reflecting my current understanding of how this works,
not trying to make claims for which I'm unsure if they're true.

What we'd really need is to put some kind of metric here, to see if this branch
is ever hit on the wild.

[Sven Panne, 2014-02-19 12:41:19]

LGTM (still), although my "mind blow" has not gone away completely ;-)

[marja, 2014-02-19 14:50:45]

Committed patchset #3 manually as r19492 (presubmit successful).