80706 2012-03-09 09:48:53 -0800 Improve ContainerNode's collectNodes() performance 2025-07-27 07:25:41 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 senorblanco senorblanco abarth darin eric kling koivisto morrita rniwa rreno webkit.review.bot oldest_to_newest 574966 0 senorblanco 2012-03-09 09:48:53 -0800 This seems to be causing regressions in Chromium's dom_perf suite. 574985 1 131056 senorblanco 2012-03-09 10:22:14 -0800 Created attachment 131056 Patch 574986 2 131056 abarth 2012-03-09 10:23:31 -0800 Comment on attachment 131056 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131056&action=review > Source/WebCore/dom/ContainerNode.cpp:68 > + size_t newSize = nodes.size(); > + for (Node* child = node->firstChild(); child; child = child->nextSibling()) > + newSize++; There's already a function that does. We might need to change the type of |node| to ContainerNode to see it. 575000 3 131056 rniwa 2012-03-09 10:43:19 -0800 Comment on attachment 131056 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131056&action=review >> Source/WebCore/dom/ContainerNode.cpp:68 >> + newSize++; > > There's already a function that does. We might need to change the type of |node| to ContainerNode to see it. childNodeCount 575007 4 senorblanco 2012-03-09 10:58:31 -0800 (In reply to comment #2) > (From update of attachment 131056 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=131056&action=review > > > Source/WebCore/dom/ContainerNode.cpp:68 > > + size_t newSize = nodes.size(); > > + for (Node* child = node->firstChild(); child; child = child->nextSibling()) > > + newSize++; > > There's already a function that does. We might need to change the type of |node| to ContainerNode to see it. Unfortunately, that requires changing collectTargetNodes(), and a number of call sites pass in a plain ol' Node to collectTargetNodes() (which can't be blindly downcast, I presume). I could move childNodeCount() up to Node, but considering this is just a speculative fix for which I'd like to get some data off the perf bots, maybe we could try it as-is? 575017 5 131056 rniwa 2012-03-09 11:04:31 -0800 Comment on attachment 131056 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131056&action=review >>>> Source/WebCore/dom/ContainerNode.cpp:68 >>>> + newSize++; >>> >>> There's already a function that does. We might need to change the type of |node| to ContainerNode to see it. >> >> childNodeCount > > Unfortunately, that requires changing collectTargetNodes(), and a number of call sites pass in a plain ol' Node to collectTargetNodes() (which can't be blindly downcast, I presume). > > I could move childNodeCount() up to Node, but considering this is just a speculative fix for which I'd like to get some data off the perf bots, maybe we could try it as-is? All nodes that have children are ContainerNodes so caller can either downcast the pointer or never call this function depending on the type of the node. 575036 6 131065 senorblanco 2012-03-09 11:46:01 -0800 Created attachment 131065 Patch 575044 7 131065 rniwa 2012-03-09 11:56:16 -0800 Comment on attachment 131065 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131065&action=review > Source/WebCore/dom/ContainerNode.cpp:78 > - collectNodes(node, nodes); > + if (!node->isContainerNode()) > + return; node is a DocumentFragment (which inherits from ContainerNode) at this point so there's no need to call isContainerNode. 575070 8 rniwa 2012-03-09 12:18:21 -0800 As I've privately told you, bumping up the initial capacity will probably buy us more performance than allocating the entire buffer up front. 575109 9 131081 senorblanco 2012-03-09 12:54:32 -0800 Created attachment 131081 Patch 575132 10 131081 eric 2012-03-09 13:05:44 -0800 Comment on attachment 131081 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131081&action=review > Source/WebCore/ChangeLog:9 > + Covered by existing tests. You need to explain what tests this improves performance on. > Source/WebCore/dom/ContainerNode.cpp:66 > + nodes.reserveCapacity(nodes.size() + node->childNodeCount()); I believe childNodeCount() walks all the node pointers... but I could imagine avoiding multiple mallocs would be faster. > Source/WebCore/dom/ContainerNode.cpp:77 > - collectNodes(node, nodes); > + collectNodes(static_cast<ContainerNode*>(node), nodes); This doesn't seem safe. 575149 11 131081 rniwa 2012-03-09 13:18:38 -0800 Comment on attachment 131081 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131081&action=review >> Source/WebCore/dom/ContainerNode.cpp:77 >> + collectNodes(static_cast<ContainerNode*>(node), nodes); > > This doesn't seem safe. This is okay because node is a DocumentFragment at this point. See line 73 :) But it might be better to cast it to DocumentFragment for clarity. 575152 12 131081 eric 2012-03-09 13:22:37 -0800 Comment on attachment 131081 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131081&action=review >>> Source/WebCore/dom/ContainerNode.cpp:77 >>> + collectNodes(static_cast<ContainerNode*>(node), nodes); >> >> This doesn't seem safe. > > This is okay because node is a DocumentFragment at this point. See line 73 :) > But it might be better to cast it to DocumentFragment for clarity. Ah yes, I had read the above as the DocumentFramgment-only special case, missed the !=. You're right though, casing to DocumentFragment would probably be more clear. 575261 13 131081 abarth 2012-03-09 14:50:10 -0800 Comment on attachment 131081 Patch Please update the ChangeLog before landing. 575265 14 131118 senorblanco 2012-03-09 14:54:51 -0800 Created attachment 131118 Patch 575266 15 131081 senorblanco 2012-03-09 14:55:47 -0800 Comment on attachment 131081 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131081&action=review >> Source/WebCore/ChangeLog:9 >> + Covered by existing tests. > > You need to explain what tests this improves performance on. Done. Note that this is a speculative fix: I'm going to land it and evalute it based on the listed tests. If there's no improvement, I'll revert. >>>> Source/WebCore/dom/ContainerNode.cpp:77 >>>> + collectNodes(static_cast<ContainerNode*>(node), nodes); >>> >>> This doesn't seem safe. >> >> This is okay because node is a DocumentFragment at this point. See line 73 :) >> But it might be better to cast it to DocumentFragment for clarity. > > Ah yes, I had read the above as the DocumentFramgment-only special case, missed the !=. You're right though, casing to DocumentFragment would probably be more clear. OK, done. 575267 16 131118 rniwa 2012-03-09 14:55:54 -0800 Comment on attachment 131118 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=131118&action=review > Source/WebCore/ChangeLog:9 > + Covered by existing tests. Performance will be evaluated based on Nit: we use one space after period. 575395 17 senorblanco 2012-03-09 18:23:30 -0800 Committed r110358: <http://trac.webkit.org/changeset/110358> 575521 18 senorblanco 2012-03-10 08:14:11 -0800 Result: the tests of interest showed no change (positive or negative) after this CL, so I'm going to revert it. e.g., http://build.chromium.org/f/chromium/perf/linux-release-webkit-latest/bloat-http/report.html?history=150&rev=-1 (change corresponds to Chrome r125985 on that chart). 575526 19 senorblanco 2012-03-10 09:19:04 -0800 Rolled out in http://trac.webkit.org/changeset/110378. 578033 20 rniwa 2012-03-13 17:28:18 -0700 I've looked into how many nodes are typically inserted by the following diff: ndex: Source/WebCore/dom/ContainerNode.cpp =================================================================== --- Source/WebCore/dom/ContainerNode.cpp (revision 110541) +++ Source/WebCore/dom/ContainerNode.cpp (working copy) @@ -65,6 +65,7 @@ { for (Node* child = node->firstChild(); child; child = child->nextSibling()) nodes.append(child); + fprintf(stderr, "[%ld]\n", nodes.size()); } and browsed on popular websites like facebook, twitter, gmail, etc... sample size: 188272 Statistics ignoring entries with 0s and 1s: mean: 4.41114811377 std: 3.31585908742 min: 2 max: 151 nodes.size() > 5: 9908 5.26% nodes.size() > 10: 2471 1.31% nodes.size() > 11: 915 0.49% nodes.size() > 12: 863 0.46% nodes.size() > 13: 834 0.44% nodes.size() > 15: 154 0.082% 11 is probably a good number to use. 578047 21 131762 rniwa 2012-03-13 17:36:26 -0700 Created attachment 131762 Increases the stack allocated buffer size 578064 22 131762 senorblanco 2012-03-13 18:05:52 -0700 Comment on attachment 131762 Increases the stack allocated buffer size View in context: https://bugs.webkit.org/attachment.cgi?id=131762&action=review > Source/WebCore/dom/ContainerNode.cpp:58 > +typedef Vector<RefPtr<Node>, 11> NodeVector; You should probably add a comment explaining how you arrived at this number. 578071 23 rniwa 2012-03-13 18:16:03 -0700 (In reply to comment #22) > (From update of attachment 131762 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=131762&action=review > > > Source/WebCore/dom/ContainerNode.cpp:58 > > +typedef Vector<RefPtr<Node>, 11> NodeVector; > > You should probably add a comment explaining how you arrived at this number. We don't normally add that kind of comment in the code. Instead, we tend to document those things in the change log. 578291 24 senorblanco 2012-03-14 03:35:39 -0700 (In reply to comment #23) > (In reply to comment #22) > > (From update of attachment 131762 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=131762&action=review > > > > > Source/WebCore/dom/ContainerNode.cpp:58 > > > +typedef Vector<RefPtr<Node>, 11> NodeVector; > > > > You should probably add a comment explaining how you arrived at this number. > > We don't normally add that kind of comment in the code. Instead, we tend to document those things in the change log. My understanding of WebKit's policy on comments is that code should be self-documenting, through the use of descriptive variable names and the like. A magic value in the code is not self-documenting. The next developer who discovers this value in the code would have to root around in the VCS to find out the change which added it, and then look up the ChangeLog to find the reasoning. 578487 25 rniwa 2012-03-14 09:29:54 -0700 (In reply to comment #24) > My understanding of WebKit's policy on comments is that code should be self-documenting, through the use of descriptive variable names and the like. A magic value in the code is not self-documenting. The next developer who discovers this value in the code would have to root around in the VCS to find out the change which added it, and then look up the ChangeLog to find the reasoning. e.g. http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSStyleSelector.cpp#L1143 As much as I understand where you're coming from, WebKit has a very different policy and culture from Google/Chromium. Please respect that. 578550 26 senorblanco 2012-03-14 10:48:32 -0700 (In reply to comment #25) > (In reply to comment #24) > > My understanding of WebKit's policy on comments is that code should be self-documenting, through the use of descriptive variable names and the like. A magic value in the code is not self-documenting. The next developer who discovers this value in the code would have to root around in the VCS to find out the change which added it, and then look up the ChangeLog to find the reasoning. > > e.g. > http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSStyleSelector.cpp#L1143 static const unsigned cStyleSearchThreshold = 10; ? This seems to be an example of a descriptive variable name (or at least, an attempt). If you'd do that in this patch, I think it would be an improvement, although I still think an explanation of how the value was derived wouldn't be out of place. > As much as I understand where you're coming from, WebKit has a very different policy and culture from Google/Chromium. Please respect that. That's exactly what I'm attempting to do (which is tricky, since this is not actually addressed in the coding guidelines). Here's a quote from Darin Adler which I think is relevant to this case: "In general my preference is to have comments that say things that the code does not. Many header comments I have seen repeat things already said by the names and signatures of functions. Comments that answer questions such as "why" and that are brief would make a good addition, even to a header file." 578606 27 rniwa 2012-03-14 11:45:04 -0700 (In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > My understanding of WebKit's policy on comments is that code should be self-documenting, through the use of descriptive variable names and the like. A magic value in the code is not self-documenting. The next developer who discovers this value in the code would have to root around in the VCS to find out the change which added it, and then look up the ChangeLog to find the reasoning. > > > > e.g. > > http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSStyleSelector.cpp#L1143 > > static const unsigned cStyleSearchThreshold = 10; ? > > This seems to be an example of a descriptive variable name (or at least, an attempt). If you'd do that in this patch, I think it would be an improvement, although I still think an explanation of how the value was derived wouldn't be out of place. In this case, a descriptive variable name helps because the semantics isn't clear from just seeing the value 10. However, in my patch, the semantics of 11 is vacuously clear; it's the initial size of the stack allocated buffer. Anyone who can read the code that uses Vector understands this instantly. 578609 28 131762 koivisto 2012-03-14 11:51:28 -0700 Comment on attachment 131762 Increases the stack allocated buffer size r=me. You could just make it even bigger. Looks like this type is just a temporary and the stack allocated size is essentially free. 578615 29 senorblanco 2012-03-14 11:56:49 -0700 (In reply to comment #27) > (In reply to comment #26) > > (In reply to comment #25) > > > (In reply to comment #24) > > > > My understanding of WebKit's policy on comments is that code should be self-documenting, through the use of descriptive variable names and the like. A magic value in the code is not self-documenting. The next developer who discovers this value in the code would have to root around in the VCS to find out the change which added it, and then look up the ChangeLog to find the reasoning. > > > > > > e.g. > > > http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSStyleSelector.cpp#L1143 > > > > static const unsigned cStyleSearchThreshold = 10; ? > > > > This seems to be an example of a descriptive variable name (or at least, an attempt). If you'd do that in this patch, I think it would be an improvement, although I still think an explanation of how the value was derived wouldn't be out of place. > > In this case, a descriptive variable name helps because the semantics isn't clear from just seeing the value 10. However, in my patch, the semantics of 11 is vacuously clear; it's the initial size of the stack allocated buffer. Anyone who can read the code that uses Vector understands this instantly. Again, you're missing the point. They'll understand the "what" but not the "why". If it's still unclear to you why code peppered with inexplicable literals is not maintainable, I'll just leave someone else to r+ this patch. 578617 30 koivisto 2012-03-14 11:57:51 -0700 Also the patch is sufficiently self document as-is. 578697 31 kling 2012-03-14 13:18:55 -0700 (In reply to comment #30) > Also the patch is sufficiently self document as-is. Agreed. I'd probably go with inlineCapacity=16 myself to get a more "rounded" number. Shouldn't matter if these are never used as member variables. LGTM regardless. 578963 32 rniwa 2012-03-14 17:11:20 -0700 Committed in http://trac.webkit.org/changeset/110797. 578965 33 rniwa 2012-03-14 17:11:40 -0700 Oops, wrong bug :( 578971 34 131762 webkit.review.bot 2012-03-14 17:18:50 -0700 Comment on attachment 131762 Increases the stack allocated buffer size Rejecting attachment 131762 from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: ti Koiv..." exit_code: 1 cwd: /mnt/git/webkit-commit-queue/ Parsed 2 diffs from patch file(s). patching file Source/WebCore/ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file Source/WebCore/dom/ContainerNode.cpp Hunk #1 FAILED at 55. 1 out of 1 hunk FAILED -- saving rejects to file Source/WebCore/dom/ContainerNode.cpp.rej Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--force', u'--reviewer', u'Antti Koiv..." exit_code: 1 cwd: /mnt/git/webkit-commit-queue/ Full output: http://queues.webkit.org/results/11952511 579074 35 131762 morrita 2012-03-14 20:34:00 -0700 Comment on attachment 131762 Increases the stack allocated buffer size View in context: https://bugs.webkit.org/attachment.cgi?id=131762&action=review >>>> Source/WebCore/dom/ContainerNode.cpp:58 >>>> +typedef Vector<RefPtr<Node>, 11> NodeVector; >>> >>> You should probably add a comment explaining how you arrived at this number. >> >> We don't normally add that kind of comment in the code. Instead, we tend to document those things in the change log. > > My understanding of WebKit's policy on comments is that code should be self-documenting, through the use of descriptive variable names and the like. A magic value in the code is not self-documenting. The next developer who discovers this value in the code would have to root around in the VCS to find out the change which added it, and then look up the ChangeLog to find the reasoning. Yeah, I think static const int ChildCountMoslyCovered = 11 will be fine for example. The point which should be emphasized here is that the number is nothing absolute and more empirical. 579075 36 morrita 2012-03-14 20:35:03 -0700 > > Yeah, I think static const int ChildCountMoslyCovered = 11 will be fine for example. > The point which should be emphasized here is that the number is nothing absolute and more empirical. > Oops the party looks over before I join. 579076 37 rniwa 2012-03-14 20:35:27 -0700 (In reply to comment #35) > Yeah, I think static const int ChildCountMoslyCovered = 11 will be fine for example. > The point which should be emphasized here is that the number is nothing absolute and more empirical. We normally document these things in the change log, not in the actual code base. 579089 38 rniwa 2012-03-14 20:50:50 -0700 Apparently this patch was committed in http://trac.webkit.org/changeset/110797 but mangled with my patch for https://bugs.webkit.org/show_bug.cgi?id=80900. Fixed the change log in http://trac.webkit.org/changeset/110797. 579090 39 rniwa 2012-03-14 20:51:37 -0700 I mean in http://trac.webkit.org/changeset/110817. 579103 40 rniwa 2012-03-14 21:00:38 -0700 http://crbug.com/117020 2132614 41 rreno 2025-07-25 16:55:20 -0700 I repeated Ryosuke's experiment from comment 20 today with a set of sites I chose myself. 11 still covers between 98% and 99% of all hits to collectChildNodes (which I think is the modern version of collectNodes). Still a good choice of inline size 13 years later based on my rough study. 2132724 42 rniwa 2025-07-27 07:25:41 -0700 That's good to know. I wonder if should adjust it to a round number like 16 though. 131056 2012-03-09 10:22:14 -0800 2012-03-09 11:45:54 -0800 Patch bug-80706-20120309132212.patch text/plain 1324 senorblanco SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDExMDMwMSkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEyLTAzLTA5ICBTdGVwaGVu IFdoaXRlICA8c2Vub3JibGFuY29AY2hyb21pdW0ub3JnPgorCisgICAgICAgIEltcHJvdmUgQ29u dGFpbmVyTm9kZSBjb2xsZWN0Tm9kZSgpIHBlcmZvcm1hbmNlIGJ5IHJlc2VydmluZyB2ZWN0b3IK KyAgICAgICAgY2FwYWNpdHkgdXAgZnJvbnQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD04MDcwNgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAo T09QUyEpLgorCisgICAgICAgIENvdmVyZWQgYnkgZXhpc3RpbmcgdGVzdHMuCisKKyAgICAgICAg KiBkb20vQ29udGFpbmVyTm9kZS5jcHA6CisgICAgICAgIChXZWJDb3JlOjpjb2xsZWN0Tm9kZXMp OgorCiAyMDEyLTAzLTA5ICBOYXRlIENoYXBpbiAgPGphcGhldEBjaHJvbWl1bS5vcmc+CiAKICAg ICAgICAgQ2FjaGVkUmF3UmVzb3VyY2UgYnJlYWtzIHdoZW4gdHJ5aW5nIHRvIGxvYWQKSW5kZXg6 IFNvdXJjZS9XZWJDb3JlL2RvbS9Db250YWluZXJOb2RlLmNwcAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3Vy Y2UvV2ViQ29yZS9kb20vQ29udGFpbmVyTm9kZS5jcHAJKHJldmlzaW9uIDExMDMwMSkKKysrIFNv dXJjZS9XZWJDb3JlL2RvbS9Db250YWluZXJOb2RlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNjMs NiArNjMsMTEgQEAgc3RhdGljIGJvb2wgc19zaG91bGRSZUVuYWJsZU1lbW9yeUNhY2hlQwogCiBz dGF0aWMgaW5saW5lIHZvaWQgY29sbGVjdE5vZGVzKE5vZGUqIG5vZGUsIE5vZGVWZWN0b3ImIG5v ZGVzKQogeworICAgIHNpemVfdCBuZXdTaXplID0gbm9kZXMuc2l6ZSgpOworICAgIGZvciAoTm9k ZSogY2hpbGQgPSBub2RlLT5maXJzdENoaWxkKCk7IGNoaWxkOyBjaGlsZCA9IGNoaWxkLT5uZXh0 U2libGluZygpKQorICAgICAgICBuZXdTaXplKys7CisKKyAgICBub2Rlcy5yZXNlcnZlQ2FwYWNp dHkobmV3U2l6ZSk7CiAgICAgZm9yIChOb2RlKiBjaGlsZCA9IG5vZGUtPmZpcnN0Q2hpbGQoKTsg Y2hpbGQ7IGNoaWxkID0gY2hpbGQtPm5leHRTaWJsaW5nKCkpCiAgICAgICAgIG5vZGVzLmFwcGVu ZChjaGlsZCk7CiB9Cg== 131065 2012-03-09 11:46:01 -0800 2012-03-09 12:54:26 -0800 Patch bug-80706-20120309144559.patch text/plain 1681 senorblanco SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDExMDMwMSkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEyLTAzLTA5ICBTdGVwaGVu IFdoaXRlICA8c2Vub3JibGFuY29AY2hyb21pdW0ub3JnPgorCisgICAgICAgIEltcHJvdmUgQ29u dGFpbmVyTm9kZSBjb2xsZWN0Tm9kZSgpIHBlcmZvcm1hbmNlIGJ5IHJlc2VydmluZyB2ZWN0b3IK KyAgICAgICAgY2FwYWNpdHkgdXAgZnJvbnQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD04MDcwNgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAo T09QUyEpLgorCisgICAgICAgIENvdmVyZWQgYnkgZXhpc3RpbmcgdGVzdHMuCisKKyAgICAgICAg KiBkb20vQ29udGFpbmVyTm9kZS5jcHA6CisgICAgICAgIChXZWJDb3JlOjpjb2xsZWN0Tm9kZXMp OgorCiAyMDEyLTAzLTA5ICBOYXRlIENoYXBpbiAgPGphcGhldEBjaHJvbWl1bS5vcmc+CiAKICAg ICAgICAgQ2FjaGVkUmF3UmVzb3VyY2UgYnJlYWtzIHdoZW4gdHJ5aW5nIHRvIGxvYWQKSW5kZXg6 IFNvdXJjZS9XZWJDb3JlL2RvbS9Db250YWluZXJOb2RlLmNwcAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3Vy Y2UvV2ViQ29yZS9kb20vQ29udGFpbmVyTm9kZS5jcHAJKHJldmlzaW9uIDExMDMwMSkKKysrIFNv dXJjZS9XZWJDb3JlL2RvbS9Db250YWluZXJOb2RlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNjEs OCArNjEsOSBAQCBzdGF0aWMgTm9kZUNhbGxiYWNrUXVldWUqIHNfcG9zdEF0dGFjaENhCiBzdGF0 aWMgc2l6ZV90IHNfYXR0YWNoRGVwdGg7CiBzdGF0aWMgYm9vbCBzX3Nob3VsZFJlRW5hYmxlTWVt b3J5Q2FjaGVDYWxsc0FmdGVyQXR0YWNoOwogCi1zdGF0aWMgaW5saW5lIHZvaWQgY29sbGVjdE5v ZGVzKE5vZGUqIG5vZGUsIE5vZGVWZWN0b3ImIG5vZGVzKQorc3RhdGljIGlubGluZSB2b2lkIGNv bGxlY3ROb2RlcyhDb250YWluZXJOb2RlKiBub2RlLCBOb2RlVmVjdG9yJiBub2RlcykKIHsKKyAg ICBub2Rlcy5yZXNlcnZlQ2FwYWNpdHkobm9kZXMuc2l6ZSgpICsgbm9kZS0+Y2hpbGROb2RlQ291 bnQoKSk7CiAgICAgZm9yIChOb2RlKiBjaGlsZCA9IG5vZGUtPmZpcnN0Q2hpbGQoKTsgY2hpbGQ7 IGNoaWxkID0gY2hpbGQtPm5leHRTaWJsaW5nKCkpCiAgICAgICAgIG5vZGVzLmFwcGVuZChjaGls ZCk7CiB9CkBAIC03Myw3ICs3NCwxMCBAQCBzdGF0aWMgdm9pZCBjb2xsZWN0VGFyZ2V0Tm9kZXMo Tm9kZSogbm9kCiAgICAgICAgIG5vZGVzLmFwcGVuZChub2RlKTsKICAgICAgICAgcmV0dXJuOwog ICAgIH0KLSAgICBjb2xsZWN0Tm9kZXMobm9kZSwgbm9kZXMpOworICAgIGlmICghbm9kZS0+aXND b250YWluZXJOb2RlKCkpCisgICAgICAgIHJldHVybjsKKworICAgIGNvbGxlY3ROb2RlcyhzdGF0 aWNfY2FzdDxDb250YWluZXJOb2RlKj4obm9kZSksIG5vZGVzKTsKIH0KIAogdm9pZCBDb250YWlu ZXJOb2RlOjpyZW1vdmVBbGxDaGlsZHJlbigpCg== 131081 2012-03-09 12:54:32 -0800 2012-03-09 14:55:47 -0800 Patch bug-80706-20120309155431.patch text/plain 1613 senorblanco SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDExMDMyMCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEyLTAzLTA5ICBTdGVwaGVu IFdoaXRlICA8c2Vub3JibGFuY29AY2hyb21pdW0ub3JnPgorCisgICAgICAgIEltcHJvdmUgQ29u dGFpbmVyTm9kZSBjb2xsZWN0Tm9kZSgpIHBlcmZvcm1hbmNlIGJ5IHJlc2VydmluZyB2ZWN0b3IK KyAgICAgICAgY2FwYWNpdHkgdXAgZnJvbnQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD04MDcwNgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAo T09QUyEpLgorCisgICAgICAgIENvdmVyZWQgYnkgZXhpc3RpbmcgdGVzdHMuCisKKyAgICAgICAg KiBkb20vQ29udGFpbmVyTm9kZS5jcHA6CisgICAgICAgIChXZWJDb3JlOjpjb2xsZWN0Tm9kZXMp OgorCiAyMDEyLTAzLTA5ICBSeW9zdWtlIE5pd2EgIDxybml3YUB3ZWJraXQub3JnPgogCiAgICAg ICAgIENsZWFudXAgaW5jRE9NVHJlZVZlcnNpb24gY2FsbGVycwpJbmRleDogU291cmNlL1dlYkNv cmUvZG9tL0NvbnRhaW5lck5vZGUuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJDb3JlL2Rv bS9Db250YWluZXJOb2RlLmNwcAkocmV2aXNpb24gMTEwMzIwKQorKysgU291cmNlL1dlYkNvcmUv ZG9tL0NvbnRhaW5lck5vZGUuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC02MSw4ICs2MSw5IEBAIHN0 YXRpYyBOb2RlQ2FsbGJhY2tRdWV1ZSogc19wb3N0QXR0YWNoQ2EKIHN0YXRpYyBzaXplX3Qgc19h dHRhY2hEZXB0aDsKIHN0YXRpYyBib29sIHNfc2hvdWxkUmVFbmFibGVNZW1vcnlDYWNoZUNhbGxz QWZ0ZXJBdHRhY2g7CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBjb2xsZWN0Tm9kZXMoTm9kZSogbm9k ZSwgTm9kZVZlY3RvciYgbm9kZXMpCitzdGF0aWMgaW5saW5lIHZvaWQgY29sbGVjdE5vZGVzKENv bnRhaW5lck5vZGUqIG5vZGUsIE5vZGVWZWN0b3ImIG5vZGVzKQogeworICAgIG5vZGVzLnJlc2Vy dmVDYXBhY2l0eShub2Rlcy5zaXplKCkgKyBub2RlLT5jaGlsZE5vZGVDb3VudCgpKTsKICAgICBm b3IgKE5vZGUqIGNoaWxkID0gbm9kZS0+Zmlyc3RDaGlsZCgpOyBjaGlsZDsgY2hpbGQgPSBjaGls ZC0+bmV4dFNpYmxpbmcoKSkKICAgICAgICAgbm9kZXMuYXBwZW5kKGNoaWxkKTsKIH0KQEAgLTcz LDcgKzc0LDcgQEAgc3RhdGljIHZvaWQgY29sbGVjdFRhcmdldE5vZGVzKE5vZGUqIG5vZAogICAg ICAgICBub2Rlcy5hcHBlbmQobm9kZSk7CiAgICAgICAgIHJldHVybjsKICAgICB9Ci0gICAgY29s bGVjdE5vZGVzKG5vZGUsIG5vZGVzKTsKKyAgICBjb2xsZWN0Tm9kZXMoc3RhdGljX2Nhc3Q8Q29u dGFpbmVyTm9kZSo+KG5vZGUpLCBub2Rlcyk7CiB9CiAKIHZvaWQgQ29udGFpbmVyTm9kZTo6cmVt b3ZlQWxsQ2hpbGRyZW4oKQo= 131118 2012-03-09 14:54:51 -0800 2012-03-13 17:36:13 -0700 Patch bug-80706-20120309175450.patch text/plain 2003 senorblanco SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDExMDMzMykKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE4IEBACisyMDEyLTAzLTA5ICBTdGVwaGVu IFdoaXRlICA8c2Vub3JibGFuY29AY2hyb21pdW0ub3JnPgorCisgICAgICAgIEltcHJvdmUgQ29u dGFpbmVyTm9kZSBjb2xsZWN0Tm9kZSgpIHBlcmZvcm1hbmNlIGJ5IHJlc2VydmluZyB2ZWN0b3IK KyAgICAgICAgY2FwYWNpdHkgdXAgZnJvbnQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD04MDcwNgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAo T09QUyEpLgorCisgICAgICAgIENvdmVyZWQgYnkgZXhpc3RpbmcgdGVzdHMuICBQZXJmb3JtYW5j ZSB3aWxsIGJlIGV2YWx1YXRlZCBiYXNlZCBvbgorICAgICAgICBDaHJvbWl1bSdzIHBhZ2VfY3lj bGVyX2Jsb2F0LWh0dHAsIHBhZ2VfY3ljbGVyX2ludGwxLCBhbmQKKyAgICAgICAgZHJvbWFlb19k b21jb3JlIHN1aXRlcy4KKworICAgICAgICAqIGRvbS9Db250YWluZXJOb2RlLmNwcDoKKyAgICAg ICAgKFdlYkNvcmU6OmNvbGxlY3ROb2Rlcyk6CisKIDIwMTItMDMtMDkgIFNoZXJpZmYgQm90ICA8 d2Via2l0LnJldmlldy5ib3RAZ21haWwuY29tPgogCiAgICAgICAgIFVucmV2aWV3ZWQsIHJvbGxp bmcgb3V0IHIxMTAzMDkuCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9kb20vQ29udGFpbmVyTm9kZS5j cHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvZG9tL0NvbnRhaW5lck5vZGUuY3BwCShy ZXZpc2lvbiAxMTAzMzMpCisrKyBTb3VyY2UvV2ViQ29yZS9kb20vQ29udGFpbmVyTm9kZS5jcHAJ KHdvcmtpbmcgY29weSkKQEAgLTI2LDYgKzI2LDcgQEAKICNpbmNsdWRlICJDaGlsZExpc3RNdXRh dGlvblNjb3BlLmgiCiAjaW5jbHVkZSAiQ29udGFpbmVyTm9kZUFsZ29yaXRobXMuaCIKICNpbmNs dWRlICJEZWxldGVCdXR0b25Db250cm9sbGVyLmgiCisjaW5jbHVkZSAiRG9jdW1lbnRGcmFnbWVu dC5oIgogI2luY2x1ZGUgIkV2ZW50TmFtZXMuaCIKICNpbmNsdWRlICJFeGNlcHRpb25Db2RlLmgi CiAjaW5jbHVkZSAiRmxvYXRSZWN0LmgiCkBAIC02MSw4ICs2Miw5IEBAIHN0YXRpYyBOb2RlQ2Fs bGJhY2tRdWV1ZSogc19wb3N0QXR0YWNoQ2EKIHN0YXRpYyBzaXplX3Qgc19hdHRhY2hEZXB0aDsK IHN0YXRpYyBib29sIHNfc2hvdWxkUmVFbmFibGVNZW1vcnlDYWNoZUNhbGxzQWZ0ZXJBdHRhY2g7 CiAKLXN0YXRpYyBpbmxpbmUgdm9pZCBjb2xsZWN0Tm9kZXMoTm9kZSogbm9kZSwgTm9kZVZlY3Rv ciYgbm9kZXMpCitzdGF0aWMgaW5saW5lIHZvaWQgY29sbGVjdE5vZGVzKENvbnRhaW5lck5vZGUq IG5vZGUsIE5vZGVWZWN0b3ImIG5vZGVzKQogeworICAgIG5vZGVzLnJlc2VydmVDYXBhY2l0eShu b2Rlcy5zaXplKCkgKyBub2RlLT5jaGlsZE5vZGVDb3VudCgpKTsKICAgICBmb3IgKE5vZGUqIGNo aWxkID0gbm9kZS0+Zmlyc3RDaGlsZCgpOyBjaGlsZDsgY2hpbGQgPSBjaGlsZC0+bmV4dFNpYmxp bmcoKSkKICAgICAgICAgbm9kZXMuYXBwZW5kKGNoaWxkKTsKIH0KQEAgLTczLDcgKzc1LDcgQEAg c3RhdGljIHZvaWQgY29sbGVjdFRhcmdldE5vZGVzKE5vZGUqIG5vZAogICAgICAgICBub2Rlcy5h cHBlbmQobm9kZSk7CiAgICAgICAgIHJldHVybjsKICAgICB9Ci0gICAgY29sbGVjdE5vZGVzKG5v ZGUsIG5vZGVzKTsKKyAgICBjb2xsZWN0Tm9kZXMoc3RhdGljX2Nhc3Q8RG9jdW1lbnRGcmFnbWVu dCo+KG5vZGUpLCBub2Rlcyk7CiB9CiAKIHZvaWQgQ29udGFpbmVyTm9kZTo6cmVtb3ZlQWxsQ2hp bGRyZW4oKQo= 131762 2012-03-13 17:36:26 -0700 2012-03-14 20:34:00 -0700 Increases the stack allocated buffer size bug-80706-20120313173618.patch text/plain 1319 rniwa SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDExMDY0OCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEyLTAzLTEzICBSeW9zdWtl IE5pd2EgIDxybml3YUB3ZWJraXQub3JnPgorCisgICAgICAgIEltcHJvdmUgQ29udGFpbmVyTm9k ZSdzIGNvbGxlY3ROb2RlcygpIHBlcmZvcm1hbmNlCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJr aXQub3JnL3Nob3dfYnVnLmNnaT9pZD04MDcwNgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9E WSAoT09QUyEpLgorCisgICAgICAgIEJ1bXAgdXAgdGhlIHNpemUgb2Ygc3RhY2sgYWxsb2NhdGVk IGJ1ZmZlciBmcm9tIDEgdG8gMTEuIEFjY29yZGluZyB0byB0aGUgcm91Z2ggc3R1ZHkgSSBjb25k dWN0ZWQsCisgICAgICAgIHRoaXMgd291bGQgY292ZXIgOTkuNSUgb2YgYWxsIG5vZGUgY29sbGVj dGlvbi4KKworICAgICAgICAqIGRvbS9Db250YWluZXJOb2RlLmNwcDoKKyAgICAgICAgKFdlYkNv cmUpOgorCiAyMDEyLTAzLTEzICBTaW1vbiBGcmFzZXIgIDxzaW1vbi5mcmFzZXJAYXBwbGUuY29t PgogCiAgICAgICAgIEZpeCBwb3RlbnRpYWwgY3Jhc2ggd2hlbiBsb2FkaW5nIHRlc3QgcmVzdWx0 cwpJbmRleDogU291cmNlL1dlYkNvcmUvZG9tL0NvbnRhaW5lck5vZGUuY3BwCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIFNvdXJjZS9XZWJDb3JlL2RvbS9Db250YWluZXJOb2RlLmNwcAkocmV2aXNpb24gMTEwNTQx KQorKysgU291cmNlL1dlYkNvcmUvZG9tL0NvbnRhaW5lck5vZGUuY3BwCSh3b3JraW5nIGNvcHkp CkBAIC01NSw3ICs1NSw3IEBAIHR5cGVkZWYgcGFpcjxSZWZQdHI8Tm9kZT4sIHVuc2lnbmVkPiBD YWwKIHR5cGVkZWYgcGFpcjxOb2RlQ2FsbGJhY2ssIENhbGxiYWNrUGFyYW1ldGVycz4gQ2FsbGJh Y2tJbmZvOwogdHlwZWRlZiBWZWN0b3I8Q2FsbGJhY2tJbmZvPiBOb2RlQ2FsbGJhY2tRdWV1ZTsK IAotdHlwZWRlZiBWZWN0b3I8UmVmUHRyPE5vZGU+LCAxPiBOb2RlVmVjdG9yOwordHlwZWRlZiBW ZWN0b3I8UmVmUHRyPE5vZGU+LCAxMT4gTm9kZVZlY3RvcjsKIHN0YXRpYyBOb2RlQ2FsbGJhY2tR dWV1ZSogc19wb3N0QXR0YWNoQ2FsbGJhY2tRdWV1ZTsKIAogc3RhdGljIHNpemVfdCBzX2F0dGFj aERlcHRoOwo=