85254 2012-04-30 18:21:35 -0700 PageCache autorelease should not wait until 3 seconds and 42 pages 2012-05-03 15:36:21 -0700 1 1 1 Unclassified WebKit History 528+ (Nightly build) All All RESOLVED FIXED InRadar P2 Normal --- 1 fpizlo fpizlo ap beidson ggaren oldest_to_newest 613137 0 fpizlo 2012-04-30 18:21:35 -0700 This causes horrible pathologies when a script decides to trigger navigations. <rdar://problem/11349613> 613141 1 139565 fpizlo 2012-04-30 18:23:05 -0700 Created attachment 139565 the patch 613142 2 139566 fpizlo 2012-04-30 18:24:57 -0700 Created attachment 139566 the patch And now, with a change log! 613254 3 139566 ggaren 2012-04-30 23:06:43 -0700 Comment on attachment 139566 the patch r=me 613493 4 ap 2012-05-01 10:05:00 -0700 Pathologies notwithstanding, have you investigated the reasons for existing behavior? Geoff, I realize that you wrote this code originally, but there must be some tradeoff here. 613546 5 ggaren 2012-05-01 11:17:19 -0700 > Geoff, I realize that you wrote this code originally, but there must be some tradeoff here. Actually, I didn't write the code: Ken Kocienda / Richard Williamson wrote it man years ago, and I ported it to C++. I believe the original code was solely a hack to hide page teardown costs from PLT1. Hence the number 42: 1 greater than the number of pages in PLT1. Phil and Stephanie are going to test with PLT3, to verify that the original hack was not a good idea. 614681 6 139566 beidson 2012-05-02 14:40:27 -0700 Comment on attachment 139566 the patch Results of new testing not withstanding, this seems too aggressive. If a call to autorelease comes in during a new page load, we will now be performing the work of the autorelease while also performing the work of the new page load. The user cares about the new page coming in hot, not the old suspended page being torn down "now" I think we need to look at this closer. 614685 7 beidson 2012-05-02 14:44:13 -0700 (In reply to comment #6) > (From update of attachment 139566 [details]) > If a call to autorelease comes in during a new page load... And to be clear, the call to autorelease almost always comes in during a new page load. 614686 8 fpizlo 2012-05-02 14:44:33 -0700 (In reply to comment #6) > (From update of attachment 139566 [details]) > Results of new testing not withstanding, this seems too aggressive. > > If a call to autorelease comes in during a new page load, we will now be performing the work of the autorelease while also performing the work of the new page load. > > The user cares about the new page coming in hot, not the old suspended page being torn down "now" They certainly will care very much about the page being torn down, if the GC now has twice as much work during page load. > > I think we need to look at this closer. Measuring the performance is, I think, the right approach here, rather than rejecting the change out of hand. 614696 9 beidson 2012-05-02 14:53:19 -0700 (In reply to comment #8) > (In reply to comment #6) > > (From update of attachment 139566 [details] [details]) > > Results of new testing not withstanding, this seems too aggressive. > > > > If a call to autorelease comes in during a new page load, we will now be performing the work of the autorelease while also performing the work of the new page load. > > > > The user cares about the new page coming in hot, not the old suspended page being torn down "now" > > They certainly will care very much about the page being torn down, if the GC now has twice as much work during page load. In the past we've achieved better page load performance by deferring things not related to page loading. These things include both tearing down suspended pages and performing GC, amongst many others. You're arguing the difference between performing 1x GC and 2x GC during page load. I think we should be performing 0x GC if CPU-time is needed for the load. > > > > I think we need to look at this closer. > > Measuring the performance is, I think, the right approach here, rather than rejecting the change out of hand. Benchmark driven performance *improvements* are absolutely fantastic. But one benchmark alone can not prove that a change is not a regression. 614697 10 beidson 2012-05-02 14:53:53 -0700 (In reply to comment #9) > But one benchmark alone can not prove that a change is not a regression. s/regression/real world regression/ 614702 11 fpizlo 2012-05-02 14:59:34 -0700 (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > (From update of attachment 139566 [details] [details] [details]) > > > Results of new testing not withstanding, this seems too aggressive. > > > > > > If a call to autorelease comes in during a new page load, we will now be performing the work of the autorelease while also performing the work of the new page load. > > > > > > The user cares about the new page coming in hot, not the old suspended page being torn down "now" > > > > They certainly will care very much about the page being torn down, if the GC now has twice as much work during page load. > > In the past we've achieved better page load performance by deferring things not related to page loading. > > These things include both tearing down suspended pages and performing GC, amongst many others. It should, if it prevents us from running out of memory. > > You're arguing the difference between performing 1x GC and 2x GC during page load. I think we should be performing 0x GC if CPU-time is needed for the load. Not if it increases memory usage. > > > > > > > I think we need to look at this closer. > > > > Measuring the performance is, I think, the right approach here, rather than rejecting the change out of hand. > > Benchmark driven performance *improvements* are absolutely fantastic. > > But one benchmark alone can not prove that a change is not a regression. You might notice that the patch has yet to land even despite your r-. That's because we have no intention of landing it based on only one benchmark; it will land once a broader set of evidence is collected. 614772 12 ggaren 2012-05-02 16:14:32 -0700 Brady, are you referring to measurable evidence that the current autorelease behavior is a performance improvement, or are you stating your intuition? 614804 13 beidson 2012-05-02 16:41:35 -0700 (In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #8) > > > (In reply to comment #6) > > > > (From update of attachment 139566 [details] [details] [details] [details]) > > > > Results of new testing not withstanding, this seems too aggressive. > > > > > > > > If a call to autorelease comes in during a new page load, we will now be performing the work of the autorelease while also performing the work of the new page load. > > > > > > > > The user cares about the new page coming in hot, not the old suspended page being torn down "now" > > > > > > They certainly will care very much about the page being torn down, if the GC now has twice as much work during page load. > > > > In the past we've achieved better page load performance by deferring things not related to page loading. > > > > These things include both tearing down suspended pages and performing GC, amongst many others. > > It should, if it prevents us from running out of memory. Not running out of memory and avoiding using memory at all costs are two different things. This change seems decidedly tilted towards the later. > > You're arguing the difference between performing 1x GC and 2x GC during page load. I think we should be performing 0x GC if CPU-time is needed for the load. > > Not if it increases memory usage. This is a broad statement. Having a temporarily higher watermark - assume there actually is free memory - has historically been a worthwhile tradeoff for faster page loads. What priority has changed such that we avoid temporarily using more available memory even when it would help us load faster? > > > > I think we need to look at this closer. > > > > > > Measuring the performance is, I think, the right approach here, rather than rejecting the change out of hand. > > > > Benchmark driven performance *improvements* are absolutely fantastic. > > > > But one benchmark alone can not prove that a change is not a regression. > > You might notice that the patch has yet to land even despite your r-. That's because we have no intention of landing it based on only one benchmark; it will land once a broader set of evidence is collected. The only information about plans I had in the bug was that we were going to test to PLT3 then call it a day, and that seems insufficient to me. Getting a broader set of evidence (as well as having a more in depth discussion) is all I was asking for. 614813 14 beidson 2012-05-02 16:44:07 -0700 (In reply to comment #12) > Brady, are you referring to measurable evidence that the current autorelease behavior is a performance improvement, or are you stating your intuition? Both. There is measurable evidence with PLT1. Since any measurable evidence beyond that is currently lacking, my intuition (as well as long history with this code) is all I have to go on. I've asked Stephanie to get a few specific numbers from the new PLT run which will help me move forward one way or another with this. 614821 15 fpizlo 2012-05-02 16:49:40 -0700 (In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #9) > > > (In reply to comment #8) > > > > (In reply to comment #6) > > > > > (From update of attachment 139566 [details] [details] [details] [details] [details]) > > > > > Results of new testing not withstanding, this seems too aggressive. > > > > > > > > > > If a call to autorelease comes in during a new page load, we will now be performing the work of the autorelease while also performing the work of the new page load. > > > > > > > > > > The user cares about the new page coming in hot, not the old suspended page being torn down "now" > > > > > > > > They certainly will care very much about the page being torn down, if the GC now has twice as much work during page load. > > > > > > In the past we've achieved better page load performance by deferring things not related to page loading. > > > > > > These things include both tearing down suspended pages and performing GC, amongst many others. > > > > It should, if it prevents us from running out of memory. > > Not running out of memory and avoiding using memory at all costs are two different things. This change seems decidedly tilted towards the later. > > > > You're arguing the difference between performing 1x GC and 2x GC during page load. I think we should be performing 0x GC if CPU-time is needed for the load. > > > > Not if it increases memory usage. > > This is a broad statement. Having a temporarily higher watermark - assume there actually is free memory - has historically been a worthwhile tradeoff for faster page loads. > > What priority has changed such that we avoid temporarily using more available memory even when it would help us load faster? > > > > > > I think we need to look at this closer. > > > > > > > > Measuring the performance is, I think, the right approach here, rather than rejecting the change out of hand. > > > > > > Benchmark driven performance *improvements* are absolutely fantastic. > > > > > > But one benchmark alone can not prove that a change is not a regression. > > > > You might notice that the patch has yet to land even despite your r-. That's because we have no intention of landing it based on only one benchmark; it will land once a broader set of evidence is collected. > > The only information about plans I had in the bug was that we were going to test to PLT3 then call it a day, and that seems insufficient to me. > > Getting a broader set of evidence (as well as having a more in depth discussion) is all I was asking for. What evidence other than the benchmarks we are already running would you consider sufficient? 614823 16 fpizlo 2012-05-02 16:50:17 -0700 (In reply to comment #14) > (In reply to comment #12) > > Brady, are you referring to measurable evidence that the current autorelease behavior is a performance improvement, or are you stating your intuition? > > Both. > > There is measurable evidence with PLT1. > > Since any measurable evidence beyond that is currently lacking, my intuition (as well as long history with this code) is all I have to go on. > > I've asked Stephanie to get a few specific numbers from the new PLT run which will help me move forward one way or another with this. So this was a speculative R- in case the numbers, which are still being gathered, are in line with your guess? 614833 17 beidson 2012-05-02 17:07:36 -0700 (In reply to comment #16) > (In reply to comment #14) > > (In reply to comment #12) > > > Brady, are you referring to measurable evidence that the current autorelease behavior is a performance improvement, or are you stating your intuition? > > > > Both. > > > > There is measurable evidence with PLT1. > > > > Since any measurable evidence beyond that is currently lacking, my intuition (as well as long history with this code) is all I have to go on. > > > > I've asked Stephanie to get a few specific numbers from the new PLT run which will help me move forward one way or another with this. > > So this was a speculative R- in case the numbers, which are still being gathered, are in line with your guess? No, it was an r- based on: 1 - My understanding of the issues involved with the code as-is as well as its history 2 - My desire to have a discussion of the negative side effect of the change that hadn't taken place (on the record) 3 - My desire to have a discussion of alternatives Note that the single benchmark we're running it against might not show a regression - which would be a supporting argument for the change - but would not entirely resolve any of my concerns. 614873 18 ggaren 2012-05-02 17:51:13 -0700 > There is measurable evidence with PLT1. To be clear, what PLT1 shows is: - If you load exactly 41 pages and then stop for > 3 seconds, a policy to wait 42 pages and 3 seconds is a speedup. - If you load more than 41 pages, or stop for < 3 seconds, a policy to wait 42 pages and 3 is a slowdown. That seems like pretty weak evidence in favor of this code. 614894 19 beidson 2012-05-02 18:17:46 -0700 (In reply to comment #18) > > There is measurable evidence with PLT1. > > To be clear, what PLT1 shows is: > > - If you load exactly 41 pages and then stop for > 3 seconds, a policy to wait 42 pages and 3 seconds is a speedup. > > - If you load more than 41 pages, or stop for < 3 seconds, a policy to wait 42 pages and 3 is a slowdown. > > That seems like pretty weak evidence in favor of this code. Well, it shows that. But it also shows that: - With this code in place, the runtime is A. - With code removed, the runtime is A + B. I have verified this at least 3 times since joining the project. The most recent was in early 2010. At that time, B was substantial. B can be seen as sum(C) for 41 C's. What this patch does is introduce a potential stutter of C to the start of each page load. On average, C is B/41 which might not be substantial. But some C's are much worse than others and modern complex web pages are liable to create bigger C's The additional numbers I've asked Stephanie to gather when testing this patch will tell us what C is for each page load to give us actual numerical data. If we find that the patch doesn't largely regress the new B and that all values of C are way too small to be noticed by a real world user, that would be fantastic. 615455 20 beidson 2012-05-03 11:46:43 -0700 Stephanie and Filip and I have discussed everything in email and in person and think this patch is the way to go for now. Restoring r+ on Geoff's behalf :) 615704 21 fpizlo 2012-05-03 15:36:21 -0700 Landed in http://trac.webkit.org/changeset/116027 139565 2012-04-30 18:23:05 -0700 2012-04-30 18:24:57 -0700 the patch fixpagecache_patch_1.diff text/plain 3586 fpizlo SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDExNTY5NikKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE4IEBACisyMDEyLTA0LTMwICBGaWxpcCBQ aXpsbyAgPGZwaXpsb0BhcHBsZS5jb20+CisKKyAgICAgICAgTmVlZCBhIHNob3J0IGRlc2NyaXB0 aW9uIGFuZCBidWcgVVJMIChPT1BTISkKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9P UFMhKS4KKworICAgICAgICBObyBuZXcgdGVzdHMuIChPT1BTISkKKworICAgICAgICAqIGhpc3Rv cnkvUGFnZUNhY2hlLmNwcDoKKyAgICAgICAgKFdlYkNvcmUpOgorICAgICAgICAoV2ViQ29yZTo6 UGFnZUNhY2hlOjpQYWdlQ2FjaGUpOgorICAgICAgICAoV2ViQ29yZTo6UGFnZUNhY2hlOjpyZWxl YXNlQXV0b3JlbGVhc2VkUGFnZXNOb3dEdWVUb1RpbWVyKToKKyAgICAgICAgKiBoaXN0b3J5L1Bh Z2VDYWNoZS5oOgorICAgICAgICAoUGFnZUNhY2hlKToKKwogMjAxMi0wNC0zMCAgT2xpdmVyIEh1 bnQgIDxvbGl2ZXJAYXBwbGUuY29tPgogCiAgICAgICAgIEhhcmRlbiBhcml0aG1ldGljIGluIElt YWdlQnVmZmVyRGF0YUNHCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9oaXN0b3J5L1BhZ2VDYWNoZS5j cHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvaGlzdG9yeS9QYWdlQ2FjaGUuY3BwCShy ZXZpc2lvbiAxMTU2NjcpCisrKyBTb3VyY2UvV2ViQ29yZS9oaXN0b3J5L1BhZ2VDYWNoZS5jcHAJ KHdvcmtpbmcgY29weSkKQEAgLTU1LDggKzU1LDYgQEAgdXNpbmcgbmFtZXNwYWNlIHN0ZDsKIAog bmFtZXNwYWNlIFdlYkNvcmUgewogCi1zdGF0aWMgY29uc3QgZG91YmxlIGF1dG9yZWxlYXNlSW50 ZXJ2YWwgPSAzOwotCiAjaWYgUExBVEZPUk0oQ0hST01JVU0pIHx8ICFkZWZpbmVkKE5ERUJVRykK IAogI2RlZmluZSBQQ0xPRyguLi4pIExPRyhQYWdlQ2FjaGUsICIlKnMlcyIsIGluZGVudExldmVs KjQsICIiLCBtYWtlU3RyaW5nKF9fVkFfQVJHU19fKS51dGY4KCkuZGF0YSgpKQpAQCAtMzIwLDcg KzMxOCw3IEBAIFBhZ2VDYWNoZTo6UGFnZUNhY2hlKCkKICAgICAsIG1fc2l6ZSgwKQogICAgICwg bV9oZWFkKDApCiAgICAgLCBtX3RhaWwoMCkKLSAgICAsIG1fYXV0b3JlbGVhc2VUaW1lcih0aGlz LCAmUGFnZUNhY2hlOjpyZWxlYXNlQXV0b3JlbGVhc2VkUGFnZXNOb3dPclJlc2NoZWR1bGUpCisg ICAgLCBtX2F1dG9yZWxlYXNlVGltZXIodGhpcywgJlBhZ2VDYWNoZTo6cmVsZWFzZUF1dG9yZWxl YXNlZFBhZ2VzTm93RHVlVG9UaW1lcikKICNpZiBVU0UoQUNDRUxFUkFURURfQ09NUE9TSVRJTkcp CiAgICAgLCBtX3Nob3VsZENsZWFyQmFja2luZ1N0b3JlcyhmYWxzZSkKICNlbmRpZgpAQCAtNTE0 LDE5ICs1MTIsOSBAQCB2b2lkIFBhZ2VDYWNoZTo6cmVtb3ZlRnJvbUxSVUxpc3QoSGlzdG9yCiAg ICAgfQogfQogCi12b2lkIFBhZ2VDYWNoZTo6cmVsZWFzZUF1dG9yZWxlYXNlZFBhZ2VzTm93T3JS ZXNjaGVkdWxlKFRpbWVyPFBhZ2VDYWNoZT4qIHRpbWVyKQordm9pZCBQYWdlQ2FjaGU6OnJlbGVh c2VBdXRvcmVsZWFzZWRQYWdlc05vd0R1ZVRvVGltZXIoVGltZXI8UGFnZUNhY2hlPiopCiB7Ci0g ICAgZG91YmxlIGxvYWREZWx0YSA9IGN1cnJlbnRUaW1lKCkgLSBGcmFtZUxvYWRlcjo6dGltZU9m TGFzdENvbXBsZXRlZExvYWQoKTsKLSAgICBmbG9hdCB1c2VyRGVsdGEgPSB1c2VySWRsZVRpbWUo KTsKLSAgICAKLSAgICAvLyBGSVhNRTogPHJkYXI6Ly9wcm9ibGVtLzUyMTExOTA+IFRoaXMgbGlt aXQgb2YgNDIgcmlza3MgZ3Jvd2luZyB0aGUgcGFnZSBjYWNoZSBmYXIgYmV5b25kIGl0cyBub21p bmFsIGNhcGFjaXR5LgotICAgIGlmICgodXNlckRlbHRhIDwgMC41IHx8IGxvYWREZWx0YSA8IDEu MjUpICYmIG1fYXV0b3JlbGVhc2VTZXQuc2l6ZSgpIDwgNDIpIHsKLSAgICAgICAgTE9HKFBhZ2VD YWNoZSwgIldlYkNvcmVQYWdlQ2FjaGU6IFBvc3Rwb25pbmcgcmVsZWFzZUF1dG9yZWxlYXNlZFBh Z2VzTm93T3JSZXNjaGVkdWxlKCkgLSAlZiBzaW5jZSBsYXN0IGxvYWQsICVmIHNpbmNlIGxhc3Qg aW5wdXQsICVpIG9iamVjdHMgcGVuZGluZyByZWxlYXNlIiwgbG9hZERlbHRhLCB1c2VyRGVsdGEs IG1fYXV0b3JlbGVhc2VTZXQuc2l6ZSgpKTsKLSAgICAgICAgdGltZXItPnN0YXJ0T25lU2hvdChh dXRvcmVsZWFzZUludGVydmFsKTsKLSAgICAgICAgcmV0dXJuOwotICAgIH0KLQotICAgIExPRyhQ YWdlQ2FjaGUsICJXZWJDb3JlUGFnZUNhY2hlOiBSZWxlYXNpbmcgcGFnZSBjYWNoZXMgLSAlZiBz ZWNvbmRzIHNpbmNlIGxhc3QgbG9hZCwgJWYgc2luY2UgbGFzdCBpbnB1dCwgJWkgb2JqZWN0cyBw ZW5kaW5nIHJlbGVhc2UiLCBsb2FkRGVsdGEsIHVzZXJEZWx0YSwgbV9hdXRvcmVsZWFzZVNldC5z aXplKCkpOworICAgIExPRyhQYWdlQ2FjaGUsICJXZWJDb3JlUGFnZUNhY2hlOiBSZWxlYXNpbmcg cGFnZSBjYWNoZXMgLSAlaSBvYmplY3RzIHBlbmRpbmcgcmVsZWFzZSIsIG1fYXV0b3JlbGVhc2VT ZXQuc2l6ZSgpKTsKICAgICByZWxlYXNlQXV0b3JlbGVhc2VkUGFnZXNOb3coKTsKIH0KIApAQCAt NTU4LDcgKzU0Niw3IEBAIHZvaWQgUGFnZUNhY2hlOjphdXRvcmVsZWFzZShQYXNzUmVmUHRyPEMK ICAgICBBU1NFUlQoIW1fYXV0b3JlbGVhc2VTZXQuY29udGFpbnMocGFnZS5nZXQoKSkpOwogICAg IG1fYXV0b3JlbGVhc2VTZXQuYWRkKHBhZ2UpOwogICAgIGlmICghbV9hdXRvcmVsZWFzZVRpbWVy LmlzQWN0aXZlKCkpCi0gICAgICAgIG1fYXV0b3JlbGVhc2VUaW1lci5zdGFydE9uZVNob3QoYXV0 b3JlbGVhc2VJbnRlcnZhbCk7CisgICAgICAgIG1fYXV0b3JlbGVhc2VUaW1lci5zdGFydE9uZVNo b3QoMCk7CiB9CiAKIH0gLy8gbmFtZXNwYWNlIFdlYkNvcmUKSW5kZXg6IFNvdXJjZS9XZWJDb3Jl L2hpc3RvcnkvUGFnZUNhY2hlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvaGlzdG9y eS9QYWdlQ2FjaGUuaAkocmV2aXNpb24gMTE1NjY3KQorKysgU291cmNlL1dlYkNvcmUvaGlzdG9y eS9QYWdlQ2FjaGUuaAkod29ya2luZyBjb3B5KQpAQCAtNzksNyArNzksNyBAQCBuYW1lc3BhY2Ug V2ViQ29yZSB7CiAgICAgICAgIHZvaWQgcHJ1bmUoKTsKIAogICAgICAgICB2b2lkIGF1dG9yZWxl YXNlKFBhc3NSZWZQdHI8Q2FjaGVkUGFnZT4pOwotICAgICAgICB2b2lkIHJlbGVhc2VBdXRvcmVs ZWFzZWRQYWdlc05vd09yUmVzY2hlZHVsZShUaW1lcjxQYWdlQ2FjaGU+Kik7CisgICAgICAgIHZv aWQgcmVsZWFzZUF1dG9yZWxlYXNlZFBhZ2VzTm93RHVlVG9UaW1lcihUaW1lcjxQYWdlQ2FjaGU+ Kik7CiAKICAgICAgICAgaW50IG1fY2FwYWNpdHk7CiAgICAgICAgIGludCBtX3NpemU7Cg== 139566 2012-04-30 18:24:57 -0700 2012-05-03 11:46:55 -0700 the patch fixpagecache_patch_2.diff text/plain 3728 fpizlo SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDExNTY5NikKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDIwIEBACisyMDEyLTA0LTMwICBGaWxpcCBQ aXpsbyAgPGZwaXpsb0BhcHBsZS5jb20+CisKKyAgICAgICAgUGFnZUNhY2hlIGF1dG9yZWxlYXNl IHNob3VsZCBub3Qgd2FpdCB1bnRpbCAzIHNlY29uZHMgYW5kIDQyIHBhZ2VzCisgICAgICAgIGh0 dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD04NTI1NAorICAgICAgICA8cmRh cjovL3Byb2JsZW0vMTEzNDk2MTM+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BT ISkuCisKKyAgICAgICAgTm8gbmV3IHRlc3RzLCBzaW5jZSB0aGVyZSBpcyBubyBjaGFuZ2UgaW4g YmVoYXZpb3IuCisKKyAgICAgICAgKiBoaXN0b3J5L1BhZ2VDYWNoZS5jcHA6CisgICAgICAgIChX ZWJDb3JlKToKKyAgICAgICAgKFdlYkNvcmU6OlBhZ2VDYWNoZTo6UGFnZUNhY2hlKToKKyAgICAg ICAgKFdlYkNvcmU6OlBhZ2VDYWNoZTo6cmVsZWFzZUF1dG9yZWxlYXNlZFBhZ2VzTm93RHVlVG9U aW1lcik6CisgICAgICAgICogaGlzdG9yeS9QYWdlQ2FjaGUuaDoKKyAgICAgICAgKFBhZ2VDYWNo ZSk6CisKIDIwMTItMDQtMzAgIE9saXZlciBIdW50ICA8b2xpdmVyQGFwcGxlLmNvbT4KIAogICAg ICAgICBIYXJkZW4gYXJpdGhtZXRpYyBpbiBJbWFnZUJ1ZmZlckRhdGFDRwpJbmRleDogU291cmNl L1dlYkNvcmUvaGlzdG9yeS9QYWdlQ2FjaGUuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJD b3JlL2hpc3RvcnkvUGFnZUNhY2hlLmNwcAkocmV2aXNpb24gMTE1NjY3KQorKysgU291cmNlL1dl YkNvcmUvaGlzdG9yeS9QYWdlQ2FjaGUuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC01NSw4ICs1NSw2 IEBAIHVzaW5nIG5hbWVzcGFjZSBzdGQ7CiAKIG5hbWVzcGFjZSBXZWJDb3JlIHsKIAotc3RhdGlj IGNvbnN0IGRvdWJsZSBhdXRvcmVsZWFzZUludGVydmFsID0gMzsKLQogI2lmIFBMQVRGT1JNKENI Uk9NSVVNKSB8fCAhZGVmaW5lZChOREVCVUcpCiAKICNkZWZpbmUgUENMT0coLi4uKSBMT0coUGFn ZUNhY2hlLCAiJSpzJXMiLCBpbmRlbnRMZXZlbCo0LCAiIiwgbWFrZVN0cmluZyhfX1ZBX0FSR1Nf XykudXRmOCgpLmRhdGEoKSkKQEAgLTMyMCw3ICszMTgsNyBAQCBQYWdlQ2FjaGU6OlBhZ2VDYWNo ZSgpCiAgICAgLCBtX3NpemUoMCkKICAgICAsIG1faGVhZCgwKQogICAgICwgbV90YWlsKDApCi0g ICAgLCBtX2F1dG9yZWxlYXNlVGltZXIodGhpcywgJlBhZ2VDYWNoZTo6cmVsZWFzZUF1dG9yZWxl YXNlZFBhZ2VzTm93T3JSZXNjaGVkdWxlKQorICAgICwgbV9hdXRvcmVsZWFzZVRpbWVyKHRoaXMs ICZQYWdlQ2FjaGU6OnJlbGVhc2VBdXRvcmVsZWFzZWRQYWdlc05vd0R1ZVRvVGltZXIpCiAjaWYg VVNFKEFDQ0VMRVJBVEVEX0NPTVBPU0lUSU5HKQogICAgICwgbV9zaG91bGRDbGVhckJhY2tpbmdT dG9yZXMoZmFsc2UpCiAjZW5kaWYKQEAgLTUxNCwxOSArNTEyLDkgQEAgdm9pZCBQYWdlQ2FjaGU6 OnJlbW92ZUZyb21MUlVMaXN0KEhpc3RvcgogICAgIH0KIH0KIAotdm9pZCBQYWdlQ2FjaGU6OnJl bGVhc2VBdXRvcmVsZWFzZWRQYWdlc05vd09yUmVzY2hlZHVsZShUaW1lcjxQYWdlQ2FjaGU+KiB0 aW1lcikKK3ZvaWQgUGFnZUNhY2hlOjpyZWxlYXNlQXV0b3JlbGVhc2VkUGFnZXNOb3dEdWVUb1Rp bWVyKFRpbWVyPFBhZ2VDYWNoZT4qKQogewotICAgIGRvdWJsZSBsb2FkRGVsdGEgPSBjdXJyZW50 VGltZSgpIC0gRnJhbWVMb2FkZXI6OnRpbWVPZkxhc3RDb21wbGV0ZWRMb2FkKCk7Ci0gICAgZmxv YXQgdXNlckRlbHRhID0gdXNlcklkbGVUaW1lKCk7Ci0gICAgCi0gICAgLy8gRklYTUU6IDxyZGFy Oi8vcHJvYmxlbS81MjExMTkwPiBUaGlzIGxpbWl0IG9mIDQyIHJpc2tzIGdyb3dpbmcgdGhlIHBh Z2UgY2FjaGUgZmFyIGJleW9uZCBpdHMgbm9taW5hbCBjYXBhY2l0eS4KLSAgICBpZiAoKHVzZXJE ZWx0YSA8IDAuNSB8fCBsb2FkRGVsdGEgPCAxLjI1KSAmJiBtX2F1dG9yZWxlYXNlU2V0LnNpemUo KSA8IDQyKSB7Ci0gICAgICAgIExPRyhQYWdlQ2FjaGUsICJXZWJDb3JlUGFnZUNhY2hlOiBQb3N0 cG9uaW5nIHJlbGVhc2VBdXRvcmVsZWFzZWRQYWdlc05vd09yUmVzY2hlZHVsZSgpIC0gJWYgc2lu Y2UgbGFzdCBsb2FkLCAlZiBzaW5jZSBsYXN0IGlucHV0LCAlaSBvYmplY3RzIHBlbmRpbmcgcmVs ZWFzZSIsIGxvYWREZWx0YSwgdXNlckRlbHRhLCBtX2F1dG9yZWxlYXNlU2V0LnNpemUoKSk7Ci0g ICAgICAgIHRpbWVyLT5zdGFydE9uZVNob3QoYXV0b3JlbGVhc2VJbnRlcnZhbCk7Ci0gICAgICAg IHJldHVybjsKLSAgICB9Ci0KLSAgICBMT0coUGFnZUNhY2hlLCAiV2ViQ29yZVBhZ2VDYWNoZTog UmVsZWFzaW5nIHBhZ2UgY2FjaGVzIC0gJWYgc2Vjb25kcyBzaW5jZSBsYXN0IGxvYWQsICVmIHNp bmNlIGxhc3QgaW5wdXQsICVpIG9iamVjdHMgcGVuZGluZyByZWxlYXNlIiwgbG9hZERlbHRhLCB1 c2VyRGVsdGEsIG1fYXV0b3JlbGVhc2VTZXQuc2l6ZSgpKTsKKyAgICBMT0coUGFnZUNhY2hlLCAi V2ViQ29yZVBhZ2VDYWNoZTogUmVsZWFzaW5nIHBhZ2UgY2FjaGVzIC0gJWkgb2JqZWN0cyBwZW5k aW5nIHJlbGVhc2UiLCBtX2F1dG9yZWxlYXNlU2V0LnNpemUoKSk7CiAgICAgcmVsZWFzZUF1dG9y ZWxlYXNlZFBhZ2VzTm93KCk7CiB9CiAKQEAgLTU1OCw3ICs1NDYsNyBAQCB2b2lkIFBhZ2VDYWNo ZTo6YXV0b3JlbGVhc2UoUGFzc1JlZlB0cjxDCiAgICAgQVNTRVJUKCFtX2F1dG9yZWxlYXNlU2V0 LmNvbnRhaW5zKHBhZ2UuZ2V0KCkpKTsKICAgICBtX2F1dG9yZWxlYXNlU2V0LmFkZChwYWdlKTsK ICAgICBpZiAoIW1fYXV0b3JlbGVhc2VUaW1lci5pc0FjdGl2ZSgpKQotICAgICAgICBtX2F1dG9y ZWxlYXNlVGltZXIuc3RhcnRPbmVTaG90KGF1dG9yZWxlYXNlSW50ZXJ2YWwpOworICAgICAgICBt X2F1dG9yZWxlYXNlVGltZXIuc3RhcnRPbmVTaG90KDApOwogfQogCiB9IC8vIG5hbWVzcGFjZSBX ZWJDb3JlCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9oaXN0b3J5L1BhZ2VDYWNoZS5oCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIFNvdXJjZS9XZWJDb3JlL2hpc3RvcnkvUGFnZUNhY2hlLmgJKHJldmlzaW9uIDExNTY2 NykKKysrIFNvdXJjZS9XZWJDb3JlL2hpc3RvcnkvUGFnZUNhY2hlLmgJKHdvcmtpbmcgY29weSkK QEAgLTc5LDcgKzc5LDcgQEAgbmFtZXNwYWNlIFdlYkNvcmUgewogICAgICAgICB2b2lkIHBydW5l KCk7CiAKICAgICAgICAgdm9pZCBhdXRvcmVsZWFzZShQYXNzUmVmUHRyPENhY2hlZFBhZ2U+KTsK LSAgICAgICAgdm9pZCByZWxlYXNlQXV0b3JlbGVhc2VkUGFnZXNOb3dPclJlc2NoZWR1bGUoVGlt ZXI8UGFnZUNhY2hlPiopOworICAgICAgICB2b2lkIHJlbGVhc2VBdXRvcmVsZWFzZWRQYWdlc05v d0R1ZVRvVGltZXIoVGltZXI8UGFnZUNhY2hlPiopOwogCiAgICAgICAgIGludCBtX2NhcGFjaXR5 OwogICAgICAgICBpbnQgbV9zaXplOwo=