158452 2016-06-06 17:20:31 -0700 equal(StringView, StringView) for strings should have a fast path for pointer equality 2016-06-07 14:12:43 -0700 1 1 1 Unclassified WebKit Web Template Framework WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 saam saam andersca benjamin cdumez cmarcelo commit-queue darin fpizlo ggaren gskachkov keith_miller kling mark.lam msaboff oliver rniwa sam sukolsak ysuzuki oldest_to_newest 1199793 0 saam 2016-06-06 17:20:31 -0700 JSBench does a lot of StringView::operator== that would succeed much faster if just did pointer equality on the string buffer. 1199808 1 280655 saam 2016-06-06 17:57:48 -0700 Created attachment 280655 patch 1199810 2 commit-queue 2016-06-06 17:58:51 -0700 Attachment 280655 did not pass style-queue: ERROR: Source/WTF/wtf/text/StringView.h:138: The parameter name "a" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/WTF/wtf/text/StringView.h:138: The parameter name "b" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/WTF/wtf/text/StringImpl.h:142: The parameter name "a" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/WTF/wtf/text/StringImpl.h:142: The parameter name "b" adds no information, so it should be removed. [readability/parameter_name] [5] Total errors found: 4 in 4 files If any of these errors are false positives, please file a bug against check-webkit-style. 1199811 3 280655 kling 2016-06-06 17:59:10 -0700 Comment on attachment 280655 patch r=me 1199815 4 saam 2016-06-06 18:04:23 -0700 (In reply to comment #2) > Attachment 280655 [details] did not pass style-queue: > > > ERROR: Source/WTF/wtf/text/StringView.h:138: The parameter name "a" adds no > information, so it should be removed. [readability/parameter_name] [5] > ERROR: Source/WTF/wtf/text/StringView.h:138: The parameter name "b" adds no > information, so it should be removed. [readability/parameter_name] [5] > ERROR: Source/WTF/wtf/text/StringImpl.h:142: The parameter name "a" adds no > information, so it should be removed. [readability/parameter_name] [5] > ERROR: Source/WTF/wtf/text/StringImpl.h:142: The parameter name "b" adds no > information, so it should be removed. [readability/parameter_name] [5] > Total errors found: 4 in 4 files > > > If any of these errors are false positives, please file a bug against > check-webkit-style. I'll fix before landing 1199818 5 280655 darin 2016-06-06 18:11:57 -0700 Comment on attachment 280655 patch View in context: https://bugs.webkit.org/attachment.cgi?id=280655&action=review > Source/WTF/ChangeLog:11 > + JSBench does a lot of StringView::operator== on StringViews that have > + the same underlying data pointer. We can make these types of use cases > + much faster by doing an early return in equalCommon when the underlying > + StringType's have equal data pointers. Can you help me understand more how this == on two StringViews with the same data pointer happens? I didn’t realize we were even using StringView all that much. For StringImpl, this is likely not a good optimization, because it’s highly likely that the StringImpl* itself is == the other, and much less likely that we have two distinct ones with the same length pointing at the same data. So I would probably put the optimization in StringView, not in equalCommon. > Source/WTF/wtf/text/StringImpl.h:339 > + const void* data() const { return m_data8; } If we keep this, this function needs a way longer name. It’s super unsafe to use this for anything except equalCommon. Maybe dataFor8BitEquality? 1199822 6 kling 2016-06-06 18:22:45 -0700 (In reply to comment #5) > Comment on attachment 280655 [details] > patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=280655&action=review > > > Source/WTF/ChangeLog:11 > > + JSBench does a lot of StringView::operator== on StringViews that have > > + the same underlying data pointer. We can make these types of use cases > > + much faster by doing an early return in equalCommon when the underlying > > + StringType's have equal data pointers. > > Can you help me understand more how this == on two StringViews with the same > data pointer happens? I didn’t realize we were even using StringView all > that much. Some of the JS source providers use a WTF::String internally and then just create a StringView wrapper when asked for their source. This change was really targeting the SourceCodeKey hash equality function. I was following the discussion about this on IRC and didn't realize it wasn't even mentioned here. My bad. Oh, and fair point about giving data() a much scarier name. 1199824 7 saam 2016-06-06 18:27:21 -0700 (In reply to comment #5) > Comment on attachment 280655 [details] > patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=280655&action=review > > > Source/WTF/ChangeLog:11 > > + JSBench does a lot of StringView::operator== on StringViews that have > > + the same underlying data pointer. We can make these types of use cases > > + much faster by doing an early return in equalCommon when the underlying > > + StringType's have equal data pointers. > > Can you help me understand more how this == on two StringViews with the same > data pointer happens? I didn’t realize we were even using StringView all > that much. We use it for SourceCodeKey inside JSC, which will use a StringView from SourceCode to check for text equality amongst JS programs (and eval programs, etc). We will use this in our unlinked code cache. Unlinked code cache can be used to cache unlinked byte code (i.e, bytecode that isn't tied to a scope, and in the case of a program, a global object). JSBench will stress this unlinked code cache heavily. In JSBench, we will often do comparisons on StringViews in which this optimization is profitable. Specifically, it will save us from doing an expensive string compare on long strings that are equal. > For StringImpl, this is likely not a good optimization, because it’s highly > likely that the StringImpl* itself is == the other, and much less likely > that we have two distinct ones with the same length pointing at the same > data. > > So I would probably put the optimization in StringView, not in equalCommon. > Right. I was debating whether to have this one level up or inside equalCommon. Maybe it's worth taking some data on how much this optimization will help us with StringImpl? Or should I just skip that and put the inside StringView? > > Source/WTF/wtf/text/StringImpl.h:339 > > + const void* data() const { return m_data8; } > > If we keep this, this function needs a way longer name. It’s super unsafe to > use this for anything except equalCommon. Maybe dataFor8BitEquality? Sure. If we keep it, I think we should just call it dataForBufferEquality. The buffer doesn't need to be 8 bit. 1199825 8 280655 saam 2016-06-06 18:29:29 -0700 Comment on attachment 280655 patch View in context: https://bugs.webkit.org/attachment.cgi?id=280655&action=review >>>> Source/WTF/ChangeLog:11 >>>> + StringType's have equal data pointers. >>> >>> Can you help me understand more how this == on two StringViews with the same data pointer happens? I didn’t realize we were even using StringView all that much. >>> >>> For StringImpl, this is likely not a good optimization, because it’s highly likely that the StringImpl* itself is == the other, and much less likely that we have two distinct ones with the same length pointing at the same data. >>> >>> So I would probably put the optimization in StringView, not in equalCommon. >> >> Some of the JS source providers use a WTF::String internally and then just create a StringView wrapper when asked for their source. >> >> This change was really targeting the SourceCodeKey hash equality function. I was following the discussion about this on IRC and didn't realize it wasn't even mentioned here. My bad. >> >> Oh, and fair point about giving data() a much scarier name. > > We use it for SourceCodeKey inside JSC, which will use a StringView from SourceCode > to check for text equality amongst JS programs (and eval programs, etc). We will use this > in our unlinked code cache. Unlinked code cache can be used to cache unlinked byte code > (i.e, bytecode that isn't tied to a scope, and in the case of a program, a global object). > JSBench will stress this unlinked code cache heavily. In JSBench, we will often do comparisons > on StringViews in which this optimization is profitable. Specifically, it will save us > from doing an expensive string compare on long strings that are equal. I'll add some more clarification in the ChangeLog about where this is used. 1199837 9 280655 darin 2016-06-06 18:47:23 -0700 Comment on attachment 280655 patch View in context: https://bugs.webkit.org/attachment.cgi?id=280655&action=review >>>>> Source/WTF/ChangeLog:11 >>>>> + StringType's have equal data pointers. >>>> >>>> Can you help me understand more how this == on two StringViews with the same data pointer happens? I didn’t realize we were even using StringView all that much. >>>> >>>> For StringImpl, this is likely not a good optimization, because it’s highly likely that the StringImpl* itself is == the other, and much less likely that we have two distinct ones with the same length pointing at the same data. >>>> >>>> So I would probably put the optimization in StringView, not in equalCommon. >>> >>> Some of the JS source providers use a WTF::String internally and then just create a StringView wrapper when asked for their source. >>> >>> This change was really targeting the SourceCodeKey hash equality function. I was following the discussion about this on IRC and didn't realize it wasn't even mentioned here. My bad. >>> >>> Oh, and fair point about giving data() a much scarier name. >> >> We use it for SourceCodeKey inside JSC, which will use a StringView from SourceCode >> to check for text equality amongst JS programs (and eval programs, etc). We will use this >> in our unlinked code cache. Unlinked code cache can be used to cache unlinked byte code >> (i.e, bytecode that isn't tied to a scope, and in the case of a program, a global object). >> JSBench will stress this unlinked code cache heavily. In JSBench, we will often do comparisons >> on StringViews in which this optimization is profitable. Specifically, it will save us >> from doing an expensive string compare on long strings that are equal. > > I'll add some more clarification in the ChangeLog about where this is used. I think you should do it only for StringView, and then you could do it for StringImpl if you get data that it is helpful there (seems highly unlikely unless the StringImpl functions are already missing a fast path for when the implementation pointers are equal). I can see the == function for StringView checking the pointer equality first before checking the length. Could still use equalCommon. 1199844 10 280660 saam 2016-06-06 19:03:47 -0700 Created attachment 280660 patch for landing 1199870 11 280660 commit-queue 2016-06-06 20:23:28 -0700 Comment on attachment 280660 patch for landing Clearing flags on attachment: 280660 Committed r201738: <http://trac.webkit.org/changeset/201738> 1199871 12 commit-queue 2016-06-06 20:23:36 -0700 All reviewed patches have been landed. Closing bug. 1199973 13 rniwa 2016-06-07 01:53:48 -0700 This was 2-5% progression on JSBench on iOS. 1200086 14 ggaren 2016-06-07 09:53:15 -0700 In the case of this speedup, our StringViews point to StringImpls that point to the same data but are not themselves pointer equal. The way this happens is that two documents create equivalent substrings by parsing the same cached resource. I believe this condition -- a substring StringImpl that is not pointer equal to another StringImpl but does point to the same data -- will happen any time we parse a resource from the cache (JS, HTML, or CSS), since we do not go to the trouble of uniqueing substrings. I'm not sure how commonly two such substrings will compare against each other, since you need some boundary-crossing interface in order for them to meet up. The boundary-crossing interface in this example is the JS source cache. 1200190 15 darin 2016-06-07 13:59:57 -0700 (In reply to comment #14) > In the case of this speedup, our StringViews point to StringImpls that point > to the same data but are not themselves pointer equal. Are you sure? > The way this happens is that two documents create equivalent substrings by > parsing the same cached resource. Using which StringImpl constructor? 1200192 16 ggaren 2016-06-07 14:12:43 -0700 (In reply to comment #15) > (In reply to comment #14) > > In the case of this speedup, our StringViews point to StringImpls that point > > to the same data but are not themselves pointer equal. > > Are you sure? > > > The way this happens is that two documents create equivalent substrings by > > parsing the same cached resource. > > Using which StringImpl constructor? Hmmm... Actually, in the case of JSBench, it looks like the strings point to the same characters because they originate as Identifiers in the JavaScript parser. When navigating webpages, a <script> inside an HTML document would call SourceProvider::getRange: virtual StringView source() const = 0; StringView getRange(int start, int end) const { return source().substring(start, end - start); } 280655 2016-06-06 17:57:48 -0700 2016-06-06 19:03:47 -0700 patch c-backup.diff text/plain 2961 saam SW5kZXg6IFNvdXJjZS9XVEYvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XVEYvQ2hh bmdlTG9nCShyZXZpc2lvbiAyMDE3MzQpCisrKyBTb3VyY2UvV1RGL0NoYW5nZUxvZwkod29ya2lu ZyBjb3B5KQpAQCAtMSwzICsxLDIzIEBACisyMDE2LTA2LTA2ICBTYWFtIEJhcmF0aSAgPHNiYXJh dGlAYXBwbGUuY29tPgorCisgICAgICAgIGVxdWFsQ29tbW9uIGZvciBzdHJpbmdzIHNob3VsZCBo YXZlIGEgZmFzdCBwYXRoIGZvciBwb2ludGVyIGVxdWFsaXR5CisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNTg0NTIKKworICAgICAgICBSZXZpZXdlZCBi eSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBKU0JlbmNoIGRvZXMgYSBsb3Qgb2YgU3RyaW5n Vmlldzo6b3BlcmF0b3I9PSBvbiBTdHJpbmdWaWV3cyB0aGF0IGhhdmUKKyAgICAgICAgdGhlIHNh bWUgdW5kZXJseWluZyBkYXRhIHBvaW50ZXIuIFdlIGNhbiBtYWtlIHRoZXNlIHR5cGVzIG9mIHVz ZSBjYXNlcworICAgICAgICBtdWNoIGZhc3RlciBieSBkb2luZyBhbiBlYXJseSByZXR1cm4gaW4g ZXF1YWxDb21tb24gd2hlbiB0aGUgdW5kZXJseWluZworICAgICAgICBTdHJpbmdUeXBlJ3MgaGF2 ZSBlcXVhbCBkYXRhIHBvaW50ZXJzLgorCisgICAgICAgICogd3RmL3RleHQvU3RyaW5nQ29tbW9u Lmg6CisgICAgICAgIChXVEY6OmVxdWFsQ29tbW9uKToKKyAgICAgICAgKiB3dGYvdGV4dC9TdHJp bmdJbXBsLmg6CisgICAgICAgIChXVEY6OlN0cmluZ0ltcGw6OlN0cmluZ0ltcGwpOgorICAgICAg ICAoV1RGOjpTdHJpbmdJbXBsOjpkYXRhKToKKyAgICAgICAgKiB3dGYvdGV4dC9TdHJpbmdWaWV3 Lmg6CisgICAgICAgIChXVEY6OlN0cmluZ1ZpZXc6OmRhdGEpOgorCiAyMDE2LTA2LTA0ICBBbmRl cnMgQ2FybHNzb24gIDxhbmRlcnNjYUBhcHBsZS5jb20+CiAKICAgICAgICAgR2V0IHJpZCBvZiBX b3JrSXRlbVdpbgpJbmRleDogU291cmNlL1dURi93dGYvdGV4dC9TdHJpbmdDb21tb24uaAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBTb3VyY2UvV1RGL3d0Zi90ZXh0L1N0cmluZ0NvbW1vbi5oCShyZXZpc2lvbiAy MDE3MzMpCisrKyBTb3VyY2UvV1RGL3d0Zi90ZXh0L1N0cmluZ0NvbW1vbi5oCSh3b3JraW5nIGNv cHkpCkBAIC0zMDAsNiArMzAwLDExIEBAIEFMV0FZU19JTkxJTkUgYm9vbCBlcXVhbENvbW1vbihj b25zdCBTdHIKICAgICBpZiAobGVuZ3RoICE9IGIubGVuZ3RoKCkpCiAgICAgICAgIHJldHVybiBm YWxzZTsKIAorICAgIGlmIChhLmRhdGEoKSA9PSBiLmRhdGEoKSkgeworICAgICAgICBBU1NFUlQo YS5pczhCaXQoKSA9PSBiLmlzOEJpdCgpKTsKKyAgICAgICAgcmV0dXJuIHRydWU7CisgICAgfQor CiAgICAgaWYgKGEuaXM4Qml0KCkpIHsKICAgICAgICAgaWYgKGIuaXM4Qml0KCkpCiAgICAgICAg ICAgICByZXR1cm4gZXF1YWwoYS5jaGFyYWN0ZXJzOCgpLCBiLmNoYXJhY3RlcnM4KCksIGxlbmd0 aCk7CkluZGV4OiBTb3VyY2UvV1RGL3d0Zi90ZXh0L1N0cmluZ0ltcGwuaAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBTb3VyY2UvV1RGL3d0Zi90ZXh0L1N0cmluZ0ltcGwuaAkocmV2aXNpb24gMjAxNzMzKQorKysg U291cmNlL1dURi93dGYvdGV4dC9TdHJpbmdJbXBsLmgJKHdvcmtpbmcgY29weSkKQEAgLTEzOSw2 ICsxMzksNyBAQCBjbGFzcyBTdHJpbmdJbXBsIHsKICAgICBmcmllbmQgc3RydWN0IFdURjo6VUNo YXJCdWZmZXJUcmFuc2xhdG9yOwogICAgIGZyaWVuZCBjbGFzcyBKU0M6OkxMSW50OjpEYXRhOwog ICAgIGZyaWVuZCBjbGFzcyBKU0M6OkxMSW50T2Zmc2V0c0V4dHJhY3RvcjsKKyAgICB0ZW1wbGF0 ZTx0eXBlbmFtZSBTdHJpbmdDbGFzc0EsIHR5cGVuYW1lIFN0cmluZ0NsYXNzQj4gZnJpZW5kIGJv b2wgZXF1YWxDb21tb24oY29uc3QgU3RyaW5nQ2xhc3NBJiBhLCBjb25zdCBTdHJpbmdDbGFzc0Im IGIpOwogICAgIAogcHJpdmF0ZToKICAgICBlbnVtIEJ1ZmZlck93bmVyc2hpcCB7CkBAIC0zMzUs NiArMzM2LDggQEAgcHJpdmF0ZToKICAgICAgICAgU1RSSU5HX1NUQVRTX0FERF8xNkJJVF9TVFJJ TkcyKG1fbGVuZ3RoLCB0cnVlKTsKICAgICB9CiAKKyAgICBjb25zdCB2b2lkKiBkYXRhKCkgY29u c3QgeyByZXR1cm4gbV9kYXRhODsgfQorCiBwdWJsaWM6CiAgICAgV1RGX0VYUE9SVF9TVFJJTkdf QVBJIHN0YXRpYyB2b2lkIGRlc3Ryb3koU3RyaW5nSW1wbCopOwogCkluZGV4OiBTb3VyY2UvV1RG L3d0Zi90ZXh0L1N0cmluZ1ZpZXcuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV1RGL3d0Zi90ZXh0 L1N0cmluZ1ZpZXcuaAkocmV2aXNpb24gMjAxNzMzKQorKysgU291cmNlL1dURi93dGYvdGV4dC9T dHJpbmdWaWV3LmgJKHdvcmtpbmcgY29weSkKQEAgLTEzNSw2ICsxMzUsMTAgQEAgcHVibGljOgog ICAgIHN0cnVjdCBVbmRlcmx5aW5nU3RyaW5nOwogCiBwcml2YXRlOgorICAgIHRlbXBsYXRlPHR5 cGVuYW1lIFN0cmluZ0NsYXNzQSwgdHlwZW5hbWUgU3RyaW5nQ2xhc3NCPiBmcmllbmQgYm9vbCBl cXVhbENvbW1vbihjb25zdCBTdHJpbmdDbGFzc0EmIGEsIGNvbnN0IFN0cmluZ0NsYXNzQiYgYik7 CisKKyAgICBjb25zdCB2b2lkKiBkYXRhKCkgY29uc3QgeyByZXR1cm4gbV9jaGFyYWN0ZXJzOyB9 CisKICAgICB2b2lkIGluaXRpYWxpemUoY29uc3QgTENoYXIqLCB1bnNpZ25lZCBsZW5ndGgpOwog ICAgIHZvaWQgaW5pdGlhbGl6ZShjb25zdCBVQ2hhciosIHVuc2lnbmVkIGxlbmd0aCk7CiAK 280660 2016-06-06 19:03:47 -0700 2016-06-06 20:23:28 -0700 patch for landing c-backup.diff text/plain 2070 saam SW5kZXg6IFNvdXJjZS9XVEYvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XVEYvQ2hh bmdlTG9nCShyZXZpc2lvbiAyMDE3MzQpCisrKyBTb3VyY2UvV1RGL0NoYW5nZUxvZwkod29ya2lu ZyBjb3B5KQpAQCAtMSwzICsxLDI3IEBACisyMDE2LTA2LTA2ICBTYWFtIEJhcmF0aSAgPHNiYXJh dGlAYXBwbGUuY29tPgorCisgICAgICAgIGVxdWFsKFN0cmluZ1ZpZXcsIFN0cmluZ1ZpZXcpIGZv ciBzdHJpbmdzIHNob3VsZCBoYXZlIGEgZmFzdCBwYXRoIGZvciBwb2ludGVyIGVxdWFsaXR5Cisg ICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNTg0NTIKKwor ICAgICAgICBSZXZpZXdlZCBieSBBbmRyZWFzIEtsaW5nLgorCisgICAgICAgIEpTQmVuY2ggZG9l cyBhIGxvdCBvZiBTdHJpbmdWaWV3OjpvcGVyYXRvcj09IG9uIFN0cmluZ1ZpZXdzIHRoYXQgaGF2 ZQorICAgICAgICB0aGUgc2FtZSB1bmRlcmx5aW5nIGNoYXJhY3RlcnMgcG9pbnRlci4gVGhpcyBi ZWNvbWVzIGhvdCBpbnNpZGUgSlNCZW5jaAorICAgICAgICBiZWNhdXNlIEpTQmVuY2ggaGVhdmls eSBzdHJlc3NlcyBKU0MncyBVbmxpbmtlZENvZGVDYWNoZSB3aXRoIGEgaGlnaAorICAgICAgICBo aXQgcmF0ZS4gVGhpcyBtZWFucyB0aGF0IHdoZW4gd2UgZ2V0IGEgaGl0IGluIHRoZSBjYWNoZSwg d2UgdXNlZCB0bworICAgICAgICBkbyB0aGUgbG9uZyBmb3JtIG9mIHN0cmluZyBjb21wYXJlLiBI b3dldmVyLCB3ZSB3ZXJlIG9mdGVuIGNvbXBhcmluZworICAgICAgICB0d28gU3RyaW5nVmlld3Mg dGhhdCBoYWQgdGhlIHNhbWUgdW5kZXJseWluZyBidWZmZXIgYW5kIGxlbmd0aC4KKyAgICAgICAg VGhpcyBwYXRjaCBzcGVlZHMgdGhpcyBjYXNlIHVwIHRvIHJ1biBpbiBjb25zdGFudCB0aW1lIGlu c3RlYWQgb2YKKyAgICAgICAgbGluZWFyIHRpbWUuCisKKyAgICAgICAgKiB3dGYvdGV4dC9TdHJp bmdDb21tb24uaDoKKyAgICAgICAgKFdURjo6ZXF1YWxDb21tb24pOgorICAgICAgICAqIHd0Zi90 ZXh0L1N0cmluZ0ltcGwuaDoKKyAgICAgICAgKFdURjo6U3RyaW5nSW1wbDo6U3RyaW5nSW1wbCk6 CisgICAgICAgIChXVEY6OlN0cmluZ0ltcGw6OmRhdGEpOgorICAgICAgICAqIHd0Zi90ZXh0L1N0 cmluZ1ZpZXcuaDoKKyAgICAgICAgKFdURjo6U3RyaW5nVmlldzo6ZGF0YSk6CisKIDIwMTYtMDYt MDQgIEFuZGVycyBDYXJsc3NvbiAgPGFuZGVyc2NhQGFwcGxlLmNvbT4KIAogICAgICAgICBHZXQg cmlkIG9mIFdvcmtJdGVtV2luCkluZGV4OiBTb3VyY2UvV1RGL3d0Zi90ZXh0L1N0cmluZ1ZpZXcu aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV1RGL3d0Zi90ZXh0L1N0cmluZ1ZpZXcuaAkocmV2aXNp b24gMjAxNzMzKQorKysgU291cmNlL1dURi93dGYvdGV4dC9TdHJpbmdWaWV3LmgJKHdvcmtpbmcg Y29weSkKQEAgLTEzNSw2ICsxMzUsOCBAQCBwdWJsaWM6CiAgICAgc3RydWN0IFVuZGVybHlpbmdT dHJpbmc7CiAKIHByaXZhdGU6CisgICAgZnJpZW5kIGJvb2wgZXF1YWwoU3RyaW5nVmlldywgU3Ry aW5nVmlldyk7CisKICAgICB2b2lkIGluaXRpYWxpemUoY29uc3QgTENoYXIqLCB1bnNpZ25lZCBs ZW5ndGgpOwogICAgIHZvaWQgaW5pdGlhbGl6ZShjb25zdCBVQ2hhciosIHVuc2lnbmVkIGxlbmd0 aCk7CiAKQEAgLTUyNSw2ICs1MjcsMTEgQEAgdGVtcGxhdGU8dHlwZW5hbWUgQ2hhcmFjdGVyVHlw ZSwgc2l6ZV90IAogCiBpbmxpbmUgYm9vbCBlcXVhbChTdHJpbmdWaWV3IGEsIFN0cmluZ1ZpZXcg YikKIHsKKyAgICBpZiAoYS5tX2NoYXJhY3RlcnMgPT0gYi5tX2NoYXJhY3RlcnMpIHsKKyAgICAg ICAgQVNTRVJUKGEuaXM4Qml0KCkgPT0gYi5pczhCaXQoKSk7CisgICAgICAgIHJldHVybiBhLmxl bmd0aCgpID09IGIubGVuZ3RoKCk7CisgICAgfQorICAgICAgICAKICAgICByZXR1cm4gZXF1YWxD b21tb24oYSwgYik7CiB9CiAK