[LazyParseCSS] WIP Implement token discarding

[LazyParseCSS] WIP Implement token discarding

Initial design idea:
Implement an API to CSSLazyPropertyParser to discard lazy tokens. This will
get called after some amount of time that the page is stablized
(load event + T seconds?).

The StyleSheetContents will iterate through all its styles, and have them
propagate the signal down to their lazyPropertyParsers.

Each lazy property parser will implement token discarding via introspecting
their first and last tokens. If both tokens have string backing, and the
backing string is identical (i.e. neither token points to the escaped string
pool), then we can generate a StringView that encompasses the property set.

This StringView is persisted, while the vector of tokens is completely cleared.
If the property is told to be parsed, we re-tokenize and parse from the
stored StringView.

OPEN QUESTIONS:
1. How do we tell if a token is backed by a string in the escaped string pool?
Two solutions:
  a. Make CSSParserToken store an unpacked StringView, which has a pointer to the
     impl. This can tell us if two tokens share an underlying impl.

  b. Store a HashSet<void*> (or some other container) in the lazy parsing state,
     and query it when deciding if we can discard tokens.

2. Is this scheme bug-free assuming (1) is solved?

3. What is the ideal time to discard tokens?

4. Do enough property sets begin and end with a string-backed token? Local testing is showing this is a pretty big portion.

BUG=692932

[Charlie Harrison, 2017-02-23 20:30:43]

The CQ bit was checked by csharrison@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-23 20:31:01]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Charlie Harrison, 2017-02-23 20:40:44]

Description was changed from

==========
[LazyParseCSS] WIP Implement token discarding

BUG=
==========

to

==========
[LazyParseCSS] WIP Implement token discarding

Initial design idea:
Implement an API to CSSLazyPropertyParser to discard lazy tokens. This will
get called after some amount of time that the page is stablized
(load event + T seconds?).

The StyleSheetContents will iterate through all its styles, and have them
propagate the signal down to their lazyPropertyParsers.

Each lazy property parser will implement token discarding via introspecting
their first and last tokens. If both tokens have string backing, and the
backing string is identical (i.e. neither token points to the escaped string
pool), then we can generate a StringView that encompasses the property set.

This StringView is persisted, while the vector of tokens is completely cleared.
If the property is told to be parsed, we re-tokenize and parse from the
stored StringView.

OPEN QUESTIONS:
1. How do we tell if a token is backed by a string in the escaped string pool?
Two solutions:
  a. Make CSSParserToken store an unpacked StringView, which has a pointer to
the
     impl. This can tell us if two tokens share an underlying impl.

  b. Store a HashSet<void*> (or some other container) in the lazy parsing state,
     and query it when deciding if we can discard tokens.

2. Is this scheme bug-free assuming (1) is solved?

3. What is the ideal time to discard tokens?

BUG=692932
==========

[Charlie Harrison, 2017-02-23 21:31:21]

The CQ bit was checked by csharrison@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-23 21:31:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Charlie Harrison, 2017-02-23 21:32:27]

csharrison@chromium.org changed reviewers:
+ esprehn@chromium.org

[Charlie Harrison, 2017-02-23 21:32:27]

Elliott: I came up with this hack to get string offsets from CSS tokens to
implement token discarding, and elaborated on a few areas where I'm not sure
about in the description.

I would appreciate some feedback if you have time. I like this approach the best
(assuming we can iron out details), because if we do it properly it could be a
net win for Chrome memory for sites which don't use a lot of rules.

[Charlie Harrison, 2017-02-23 21:37:49]

Description was changed from

==========
[LazyParseCSS] WIP Implement token discarding

Initial design idea:
Implement an API to CSSLazyPropertyParser to discard lazy tokens. This will
get called after some amount of time that the page is stablized
(load event + T seconds?).

The StyleSheetContents will iterate through all its styles, and have them
propagate the signal down to their lazyPropertyParsers.

Each lazy property parser will implement token discarding via introspecting
their first and last tokens. If both tokens have string backing, and the
backing string is identical (i.e. neither token points to the escaped string
pool), then we can generate a StringView that encompasses the property set.

This StringView is persisted, while the vector of tokens is completely cleared.
If the property is told to be parsed, we re-tokenize and parse from the
stored StringView.

OPEN QUESTIONS:
1. How do we tell if a token is backed by a string in the escaped string pool?
Two solutions:
  a. Make CSSParserToken store an unpacked StringView, which has a pointer to
the
     impl. This can tell us if two tokens share an underlying impl.

  b. Store a HashSet<void*> (or some other container) in the lazy parsing state,
     and query it when deciding if we can discard tokens.

2. Is this scheme bug-free assuming (1) is solved?

3. What is the ideal time to discard tokens?

BUG=692932
==========

to

==========
[LazyParseCSS] WIP Implement token discarding

Initial design idea:
Implement an API to CSSLazyPropertyParser to discard lazy tokens. This will
get called after some amount of time that the page is stablized
(load event + T seconds?).

The StyleSheetContents will iterate through all its styles, and have them
propagate the signal down to their lazyPropertyParsers.

Each lazy property parser will implement token discarding via introspecting
their first and last tokens. If both tokens have string backing, and the
backing string is identical (i.e. neither token points to the escaped string
pool), then we can generate a StringView that encompasses the property set.

This StringView is persisted, while the vector of tokens is completely cleared.
If the property is told to be parsed, we re-tokenize and parse from the
stored StringView.

OPEN QUESTIONS:
1. How do we tell if a token is backed by a string in the escaped string pool?
Two solutions:
  a. Make CSSParserToken store an unpacked StringView, which has a pointer to
the
     impl. This can tell us if two tokens share an underlying impl.

  b. Store a HashSet<void*> (or some other container) in the lazy parsing state,
     and query it when deciding if we can discard tokens.

2. Is this scheme bug-free assuming (1) is solved?

3. What is the ideal time to discard tokens?

4. Do enough property sets begin and end with a string-backed token? Local
testing is showing this is a pretty big portion.

BUG=692932
==========

[Charlie Harrison, 2017-02-23 21:37:49]

csharrison@chromium.org changed reviewers:
- esprehn@chromium.org

[commit-bot: I haz the power, 2017-02-23 22:52:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-23 22:52:16]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Charlie Harrison, 2017-02-24 02:16:37]

csharrison@chromium.org changed reviewers:
+ esprehn@chromium.org

[Charlie Harrison, 2017-02-24 02:16:37]

Oops +esprehn for real this time.

[Charlie Harrison, 2017-02-27 00:45:28]

The CQ bit was checked by csharrison@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-27 00:45:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-27 02:13:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-27 02:13:39]

Dry run: This issue passed the CQ dry run.