Summary: | Current implementation of Parser::createSavePoint is a foot gun | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Saam Barati <saam> | ||||||||||
Component: | JavaScriptCore | Assignee: | Saam Barati <saam> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | benjamin, commit-queue, fpizlo, ggaren, gskachkov, keith_miller, mark.lam, msaboff, oliver, rniwa, sukolsak, ysuzuki | ||||||||||
Priority: | P2 | ||||||||||||
Version: | WebKit Nightly Build | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Attachments: |
|
Description
Saam Barati
2016-01-20 16:06:18 PST
SavePoint should be saving everything necessary - I'm not saying it is, i'm saying that the whole point of it is to do that. SavePoint should not be a footgun, it should just be "correct" The correct solution is probably to put all parser state, and all lever state, into structs so that SavePoint can just do a struct copy and not worry about things going out of sync. Created attachment 269400 [details]
patch
(In reply to comment #1) > SavePoint should be saving everything necessary - I'm not saying it is, i'm > saying that the whole point of it is to do that. SavePoint should not be a > footgun, it should just be "correct" I agree. SavePoint should just work. I've renamed the old SavePoint to LexerState and made the new SavePoint LexerState+ParserState. (In reply to comment #1) > The correct solution is probably to put all parser state, and all lever > state, into structs so that SavePoint can just do a struct copy and not > worry about things going out of sync. That's a good idea. I'll change it so that Parser now owns a ParserState. It might not be as clean to have LexerState be this way. Created attachment 269402 [details]
patch
Created attachment 269403 [details]
patch
renamed the bug
Comment on attachment 269403 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=269403&action=review > Source/JavaScriptCore/parser/Parser.h:1302 > + ALWAYS_INLINE LexerState saveLexerState() An idea: make this internalSaveLexerState, make it private, make SavePoint a friend of lexer, and have SavePoint have a saveLexerState(Lexer*) function that calls it. But that's a somewhat convoluted so maybe not worth it? > Source/JavaScriptCore/parser/Parser.h:1368 > const Identifier* m_lastIdentifier; > const Identifier* m_lastFunctionName; We should probably pull all of these into parser state. What's the rational for not doing so? Comment on attachment 269403 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=269403&action=review >> Source/JavaScriptCore/parser/Parser.h:1302 >> + ALWAYS_INLINE LexerState saveLexerState() > > An idea: make this internalSaveLexerState, make it private, make SavePoint a friend of lexer, and have SavePoint have a saveLexerState(Lexer*) function that calls it. > > But that's a somewhat convoluted so maybe not worth it? Ok. The reason I did it this way is that there are a few places where we only need to save lexer information (i.e, one token lookahead). That said, I think it's still somewhat of a footgun to have this. Let me see what the performance is if we always use SavePoints. >> Source/JavaScriptCore/parser/Parser.h:1368 >> const Identifier* m_lastFunctionName; > > We should probably pull all of these into parser state. What's the rational for not doing so? I thought about this, and I think for correctness/completeness, we should have it. We also might want m_statementDepth there, too, even though we sometimes manage manually with DepthManager. It's perf neutral to always use SavePoints. Going to do that. I'm going to rename saveLexerState to internalSaveLexerState, but I'm going to keep it a Parser method because it consults Parser's fields. Created attachment 269594 [details]
patch
Comment on attachment 269594 [details] patch Clearing flags on attachment: 269594 Committed r195484: <http://trac.webkit.org/changeset/195484> All reviewed patches have been landed. Closing bug. This regressed Dromaeo CSS selector tests by 2.5%. (In reply to comment #13) > This regressed Dromaeo CSS selector tests by 2.5%. Writing this for the record. This patch didn't actually regress Dromaeo. Our calculations of performance showed a regression because this patch fixed a bug where one Dromaeo test wouldn't parse. Because it now passes with this patch, we showed a regression. |