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.
https://codereview.chromium.org/169223009/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
