137721 2014-10-14 15:05:30 -0700 [Mac] Fix inefficiencies in ResourceResponse::platformLazyInit(InitLevel) 2014-10-15 17:10:08 -0700 1 1 1 Unclassified WebKit Platform 528+ (Nightly build) Mac Unspecified RESOLVED FIXED P2 Enhancement --- 1 cdumez cdumez ap barraclough commit-queue darin oldest_to_newest 1041697 0 cdumez 2014-10-14 15:05:30 -0700 There are several inefficiencies with the current Mac implementation of ResourceResponse::platformLazyInit(InitLevel): 1. We end up initializing uncommon fields even if called with CommonFieldsOnly initLevel. 2. If called with AllFields initLevel (if currently uninitialized), we end up populating m_httpHeaderFields twice, once with only the common headers, then with ALL the headers. We can skip the common-header case in this case to avoid wasting CPU time. 1041699 1 239828 cdumez 2014-10-14 15:23:24 -0700 Created attachment 239828 Patch 1041730 2 239828 ggaren 2014-10-14 17:02:32 -0700 Comment on attachment 239828 Patch r=me 1041744 3 239828 commit-queue 2014-10-14 17:44:48 -0700 Comment on attachment 239828 Patch Clearing flags on attachment: 239828 Committed r174717: <http://trac.webkit.org/changeset/174717> 1041745 4 commit-queue 2014-10-14 17:46:22 -0700 All reviewed patches have been landed. Closing bug. 1041868 5 239828 darin 2014-10-15 09:30:35 -0700 Comment on attachment 239828 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=239828&action=review > Source/WebCore/platform/network/mac/ResourceResponseMac.mm:141 > + for (unsigned i = 0; i < WTF_ARRAY_LENGTH(commonHeaderFields); ++i) { This could use a modern C++ for loop and avoid the need to use WTF_ARRAY_LENGTH. > Source/WebCore/platform/network/mac/ResourceResponseMac.mm:143 > + m_httpHeaderFields.set(String(commonHeaderFields[i]), headerValue); I’m surprised we need the explicit String() here. Also, it would be a bit more efficient to create this String if we used ASCIILiteral. And in additional, HashMap::add generates slightly less code than set, which is an add followed by an optional assignment, and here we could use either, so I suggest we use add. > Source/WebCore/platform/network/mac/ResourceResponseMac.mm:164 > m_httpHeaderFields.set(String(name), [headers objectForKey:name]); I’m surprised we need the explicit String() here. 1041903 6 239828 cdumez 2014-10-15 11:10:48 -0700 Comment on attachment 239828 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=239828&action=review >> Source/WebCore/platform/network/mac/ResourceResponseMac.mm:141 >> + for (unsigned i = 0; i < WTF_ARRAY_LENGTH(commonHeaderFields); ++i) { > > This could use a modern C++ for loop and avoid the need to use WTF_ARRAY_LENGTH. Right. >> Source/WebCore/platform/network/mac/ResourceResponseMac.mm:143 >> + m_httpHeaderFields.set(String(commonHeaderFields[i]), headerValue); > > I’m surprised we need the explicit String() here. Also, it would be a bit more efficient to create this String if we used ASCIILiteral. And in additional, HashMap::add generates slightly less code than set, which is an add followed by an optional assignment, and here we could use either, so I suggest we use add. I don't think ASCIILiteral works here. Right now, we have an array of NSString*, so using a modern loop would look like for (NSString* name : commonHeaderFields). I cannot call ASCIILIteral(NSString*). It is an NSString* because it is used in [headers objectForKey:name]. Regarding the second comment. The issue is that m_httpHeaderFields is not a HashMap, it is an HTTPHeaderMap. HTTPHeaderMap::add() actually does more work because if the key is already present, it will *append* the new value to the existing value. So, either way, we end up checking !result.isNewEntry (which is never true because we clear the HashMap before this loop) and we return without further value change. In the end it is equivalent performance-wise but I think HTTPHeaderMap::add() is clearer here because we really want to set the header value, not append the new value to the existing one. >> Source/WebCore/platform/network/mac/ResourceResponseMac.mm:164 >> m_httpHeaderFields.set(String(name), [headers objectForKey:name]); > > I’m surprised we need the explicit String() here. We don't. As a matter of fact, if that constructor was explicit, we would need String([headers objectForKey:name]) as well. Also note that we could not use HTTPHeaderMap::add() here because common headers might already be in the HashMap and we would end up appending / duplicating the value, instead of overwriting it. 1041904 7 cdumez 2014-10-15 11:13:18 -0700 (In reply to comment #6) > (From update of attachment 239828 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=239828&action=review > > >> Source/WebCore/platform/network/mac/ResourceResponseMac.mm:141 > >> + for (unsigned i = 0; i < WTF_ARRAY_LENGTH(commonHeaderFields); ++i) { > > > > This could use a modern C++ for loop and avoid the need to use WTF_ARRAY_LENGTH. > > Right. > > >> Source/WebCore/platform/network/mac/ResourceResponseMac.mm:143 > >> + m_httpHeaderFields.set(String(commonHeaderFields[i]), headerValue); > > > > I’m surprised we need the explicit String() here. Also, it would be a bit more efficient to create this String if we used ASCIILiteral. And in additional, HashMap::add generates slightly less code than set, which is an add followed by an optional assignment, and here we could use either, so I suggest we use add. > > I don't think ASCIILiteral works here. Right now, we have an array of NSString*, so using a modern loop would look like for (NSString* name : commonHeaderFields). I cannot call ASCIILIteral(NSString*). It is an NSString* because it is used in [headers objectForKey:name]. > > Regarding the second comment. The issue is that m_httpHeaderFields is not a HashMap, it is an HTTPHeaderMap. HTTPHeaderMap::add() actually does more work because if the key is already present, it will *append* the new value to the existing value. So, either way, we end up checking !result.isNewEntry (which is never true because we clear the HashMap before this loop) and we return without further value change. In the end it is equivalent performance-wise but I think HTTPHeaderMap::add() is clearer here because we really want to set the header value, not append the new value to the existing one. typo: I meant "HTTPHeaderMap::set() is clearer* 1041905 8 239879 cdumez 2014-10-15 11:16:28 -0700 Created attachment 239879 Follow-up patch for nits. 1041928 9 cdumez 2014-10-15 12:59:07 -0700 Reopening to fix nits. 1041998 10 239828 darin 2014-10-15 16:15:08 -0700 Comment on attachment 239828 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=239828&action=review >>> Source/WebCore/platform/network/mac/ResourceResponseMac.mm:143 >>> + m_httpHeaderFields.set(String(commonHeaderFields[i]), headerValue); >> >> I’m surprised we need the explicit String() here. Also, it would be a bit more efficient to create this String if we used ASCIILiteral. And in additional, HashMap::add generates slightly less code than set, which is an add followed by an optional assignment, and here we could use either, so I suggest we use add. > > I don't think ASCIILiteral works here. Right now, we have an array of NSString*, so using a modern loop would look like for (NSString* name : commonHeaderFields). I cannot call ASCIILIteral(NSString*). It is an NSString* because it is used in [headers objectForKey:name]. > > Regarding the second comment. The issue is that m_httpHeaderFields is not a HashMap, it is an HTTPHeaderMap. HTTPHeaderMap::add() actually does more work because if the key is already present, it will *append* the new value to the existing value. So, either way, we end up checking !result.isNewEntry (which is never true because we clear the HashMap before this loop) and we return without further value change. In the end it is equivalent performance-wise but I think HTTPHeaderMap::add() is clearer here because we really want to set the header value, not append the new value to the existing one. Makes sense, my comment was about HashMap::set, not about HTTPHeaderMap::set! If the performance of this function matters enough, we should consider a separate array containing each of the common header field names in WTF::String form; seems wasteful to convert from NSString to WTF::String each time. 1042002 11 cdumez 2014-10-15 16:24:31 -0700 (In reply to comment #10) > (From update of attachment 239828 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=239828&action=review > > >>> Source/WebCore/platform/network/mac/ResourceResponseMac.mm:143 > >>> + m_httpHeaderFields.set(String(commonHeaderFields[i]), headerValue); > >> > >> I’m surprised we need the explicit String() here. Also, it would be a bit more efficient to create this String if we used ASCIILiteral. And in additional, HashMap::add generates slightly less code than set, which is an add followed by an optional assignment, and here we could use either, so I suggest we use add. > > > > I don't think ASCIILiteral works here. Right now, we have an array of NSString*, so using a modern loop would look like for (NSString* name : commonHeaderFields). I cannot call ASCIILIteral(NSString*). It is an NSString* because it is used in [headers objectForKey:name]. > > > > Regarding the second comment. The issue is that m_httpHeaderFields is not a HashMap, it is an HTTPHeaderMap. HTTPHeaderMap::add() actually does more work because if the key is already present, it will *append* the new value to the existing value. So, either way, we end up checking !result.isNewEntry (which is never true because we clear the HashMap before this loop) and we return without further value change. In the end it is equivalent performance-wise but I think HTTPHeaderMap::add() is clearer here because we really want to set the header value, not append the new value to the existing one. > > Makes sense, my comment was about HashMap::set, not about HTTPHeaderMap::set! > > If the performance of this function matters enough, we should consider a separate array containing each of the common header field names in WTF::String form; seems wasteful to convert from NSString to WTF::String each time. I don't think it is worth it. Based on my investigation, we mostly call this function with AllFields initLevel (rarely CommonFieldsOnly). This is usually triggered by serialization for the IPC between the NetworkProcess and the WebProcess. FYI, what is hot in this function right now is: m_url = [m_nsResponse.get() URL]; // 7.1% m_mimeType = [m_nsResponse.get() MIMEType]; // 7.1% m_expectedContentLength = [m_nsResponse.get() expectedContentLength]; // 7.1% m_textEncodingName = [m_nsResponse.get() textEncodingName]; // 28.6% if (RetainPtr<NSString> httpStatusLine = adoptNS(wkCopyNSURLResponseStatusLine(httpResponse))) // 7.1% for (NSString *name in headers) // 7.1% m_httpHeaderFields.set(String(name), [headers objectForKey:name]); // 21.4% [pool drain]; // 7.1% 1042012 12 239879 commit-queue 2014-10-15 17:10:03 -0700 Comment on attachment 239879 Follow-up patch for nits. Clearing flags on attachment: 239879 Committed r174747: <http://trac.webkit.org/changeset/174747> 1042013 13 commit-queue 2014-10-15 17:10:08 -0700 All reviewed patches have been landed. Closing bug. 239828 2014-10-14 15:23:24 -0700 2014-10-15 16:15:08 -0700 Patch bug-137721-20141014152329.patch text/plain 4351 cdumez U3VidmVyc2lvbiBSZXZpc2lvbjogMTc0Njk4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNTY0N2UyMTk0ZWIxYWQ3 MTZhMTY3MDFkZDE2MDIwY2UwYzQ3ZDEwZC4uY2MyNDEyNWE4NzVhZDRjODMzZTAwYzIyOGY2MmY3 YTM2NDc3NjdlNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDMyIEBACisyMDE0LTEwLTE0ICBDaHJp cyBEdW1leiAgPGNkdW1lekBhcHBsZS5jb20+CisKKyAgICAgICAgW01hY10gRml4IGluZWZmaWNp ZW5jaWVzIGluIFJlc291cmNlUmVzcG9uc2U6OnBsYXRmb3JtTGF6eUluaXQoSW5pdExldmVsKQor ICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTM3NzIxCisK KyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgVGhlcmUgd2Vy ZSBzZXZlcmFsIGluZWZmaWNpZW5jaWVzIHdpdGggdGhlIE1hYyBpbXBsZW1lbnRhdGlvbiBvZgor ICAgICAgICBSZXNvdXJjZVJlc3BvbnNlOjpwbGF0Zm9ybUxhenlJbml0KEluaXRMZXZlbCk6Cisg ICAgICAgIDEuIFdlIGVuZCB1cCBpbml0aWFsaXppbmcgdW5jb21tb24gZmllbGRzIGV2ZW4gaWYg Y2FsbGVkIHdpdGgKKyAgICAgICAgICAgJ0NvbW1vbkZpZWxkc09ubHknIGluaXRMZXZlbC4KKyAg ICAgICAgMi4gSWYgY2FsbGVkIHdpdGggJ0FsbEZpZWxkcycgaW5pdExldmVsIChhbmQgaWYgY3Vy cmVudGx5CisgICAgICAgICAgIHVuaW5pdGlhbGl6ZWQpLCB3ZSBlbmQgdXAgcG9wdWxhdGluZyBt X2h0dHBIZWFkZXJGaWVsZHMgdHdpY2UsIG9uY2UKKyAgICAgICAgICAgd2l0aCBvbmx5IHRoZSBj b21tb24gaGVhZGVycywgdGhlbiBhIHNlY29uZCB0aW1lIHdpdGggQUxMIHRoZQorICAgICAgICAg ICBoZWFkZXJzLiBXZSBjYW4gc2tpcCB0aGUgY29tbW9uLWhlYWRlciBjYXNlIGluIHRoaXMgY2Fz ZSB0byBhdm9pZAorICAgICAgICAgICB3YXN0aW5nIENQVSB0aW1lLgorCisgICAgICAgIFRoaXMg cGF0Y2ggYWRkcmVzc2VzIGJvdGggaW5lZmZpY2llbmNpZXMgYW5kIGNsZWFucyB1cCB0aGUgY29k ZSBhCisgICAgICAgIGxpdHRsZSBiaXQgdG8gcmVkdWNlIHZhcmlhYmxlIHNjb3BlIGFuZCB0byB1 c2UgZmFzdCBlbnVtZXJhdGlvbiBvZgorICAgICAgICBoZWFkZXIgbmFtZXMuCisKKyAgICAgICAg QXMgYSByZXN1bHQsIHdlIHNwZW5kIGFsbW9zdCB0d2ljZSBhcyBsaXR0bGUgdGltZSBpbiBwbGF0 Zm9ybUxhenlJbml0KCkKKyAgICAgICAgd2hlbiBsb2FkaW5nIG1zbi5jb20gKH4zMG1zIC0+IH4x OG1zKS4KKworICAgICAgICBObyBuZXcgdGVzdHMsIG5vIGJlaGF2aW9yIGNoYW5nZS4KKworICAg ICAgICAqIHBsYXRmb3JtL25ldHdvcmsvbWFjL1Jlc291cmNlUmVzcG9uc2VNYWMubW06CisgICAg ICAgIChXZWJDb3JlOjpSZXNvdXJjZVJlc3BvbnNlOjpwbGF0Zm9ybUxhenlJbml0KToKKwogMjAx NC0xMC0xNCAgQnJlbnQgRnVsZ2hhbSAgPGJmdWxnaGFtQGFwcGxlLmNvbT4KIAogICAgICAgICBb V2luXSBFbmFibGUgRW5jcnlwdGVkIE1lZGlhIFN1cHBvcnQKZGlmZiAtLWdpdCBhL1NvdXJjZS9X ZWJDb3JlL3BsYXRmb3JtL25ldHdvcmsvbWFjL1Jlc291cmNlUmVzcG9uc2VNYWMubW0gYi9Tb3Vy Y2UvV2ViQ29yZS9wbGF0Zm9ybS9uZXR3b3JrL21hYy9SZXNvdXJjZVJlc3BvbnNlTWFjLm1tCmlu ZGV4IDUzZjdmMDAwYTZjZTk2YWUwZWU3OWUxNzBhNWVhNjM3MjE2NmU3OGMuLjRlOTdhMzU3MzQ1 MzA1ZDA1N2QxMmY1ZjBkYzVhMjBhZTY2OTRhNWQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3Jl L3BsYXRmb3JtL25ldHdvcmsvbWFjL1Jlc291cmNlUmVzcG9uc2VNYWMubW0KKysrIGIvU291cmNl L1dlYkNvcmUvcGxhdGZvcm0vbmV0d29yay9tYWMvUmVzb3VyY2VSZXNwb25zZU1hYy5tbQpAQCAt MTM1LDEyICsxMzUsMTMgQEAgdm9pZCBSZXNvdXJjZVJlc3BvbnNlOjpwbGF0Zm9ybUxhenlJbml0 KEluaXRMZXZlbCBpbml0TGV2ZWwpCiAgICAgICAgICAgICBOU0hUVFBVUkxSZXNwb25zZSAqaHR0 cFJlc3BvbnNlID0gKE5TSFRUUFVSTFJlc3BvbnNlICopbV9uc1Jlc3BvbnNlLmdldCgpOwogCiAg ICAgICAgICAgICBtX2h0dHBTdGF0dXNDb2RlID0gW2h0dHBSZXNwb25zZSBzdGF0dXNDb2RlXTsK LQotICAgICAgICAgICAgTlNEaWN0aW9uYXJ5ICpoZWFkZXJzID0gW2h0dHBSZXNwb25zZSBhbGxI ZWFkZXJGaWVsZHNdOwogICAgICAgICAgICAgCi0gICAgICAgICAgICBmb3IgKHVuc2lnbmVkIGkg PSAwOyBpIDwgV1RGX0FSUkFZX0xFTkdUSChjb21tb25IZWFkZXJGaWVsZHMpOyArK2kpIHsKLSAg ICAgICAgICAgICAgICBpZiAoTlNTdHJpbmcqIGhlYWRlclZhbHVlID0gW2hlYWRlcnMgb2JqZWN0 Rm9yS2V5OmNvbW1vbkhlYWRlckZpZWxkc1tpXV0pCi0gICAgICAgICAgICAgICAgICAgIG1faHR0 cEhlYWRlckZpZWxkcy5zZXQoU3RyaW5nKGNvbW1vbkhlYWRlckZpZWxkc1tpXSksIGhlYWRlclZh bHVlKTsKKyAgICAgICAgICAgIGlmIChpbml0TGV2ZWwgPCBBbGxGaWVsZHMpIHsKKyAgICAgICAg ICAgICAgICBOU0RpY3Rpb25hcnkgKmhlYWRlcnMgPSBbaHR0cFJlc3BvbnNlIGFsbEhlYWRlckZp ZWxkc107CisgICAgICAgICAgICAgICAgZm9yICh1bnNpZ25lZCBpID0gMDsgaSA8IFdURl9BUlJB WV9MRU5HVEgoY29tbW9uSGVhZGVyRmllbGRzKTsgKytpKSB7CisgICAgICAgICAgICAgICAgICAg IGlmIChOU1N0cmluZyogaGVhZGVyVmFsdWUgPSBbaGVhZGVycyBvYmplY3RGb3JLZXk6Y29tbW9u SGVhZGVyRmllbGRzW2ldXSkKKyAgICAgICAgICAgICAgICAgICAgICAgIG1faHR0cEhlYWRlckZp ZWxkcy5zZXQoU3RyaW5nKGNvbW1vbkhlYWRlckZpZWxkc1tpXSksIGhlYWRlclZhbHVlKTsKKyAg ICAgICAgICAgICAgICB9CiAgICAgICAgICAgICB9CiAgICAgICAgIH0gZWxzZQogICAgICAgICAg ICAgbV9odHRwU3RhdHVzQ29kZSA9IDA7CkBAIC0xNDgsMjEgKzE0OSwxOCBAQCB2b2lkIFJlc291 cmNlUmVzcG9uc2U6OnBsYXRmb3JtTGF6eUluaXQoSW5pdExldmVsIGluaXRMZXZlbCkKICAgICAg ICAgW3Bvb2wgZHJhaW5dOwogICAgIH0KIAotICAgIGlmIChtX2luaXRMZXZlbCA8IEFsbEZpZWxk cykgeworICAgIGlmIChtX2luaXRMZXZlbCA8IEFsbEZpZWxkcyAmJiBpbml0TGV2ZWwgPT0gQWxs RmllbGRzKSB7CiAgICAgICAgIGlmIChbbV9uc1Jlc3BvbnNlLmdldCgpIGlzS2luZE9mQ2xhc3M6 W05TSFRUUFVSTFJlc3BvbnNlIGNsYXNzXV0pIHsKICAgICAgICAgICAgIE5TQXV0b3JlbGVhc2VQ b29sKiBwb29sID0gW1tOU0F1dG9yZWxlYXNlUG9vbCBhbGxvY10gaW5pdF07CiAKICAgICAgICAg ICAgIE5TSFRUUFVSTFJlc3BvbnNlICpodHRwUmVzcG9uc2UgPSAoTlNIVFRQVVJMUmVzcG9uc2Ug KiltX25zUmVzcG9uc2UuZ2V0KCk7Ci0KLSAgICAgICAgICAgIFJldGFpblB0cjxOU1N0cmluZz4g aHR0cFN0YXR1c0xpbmUgPSBhZG9wdE5TKHdrQ29weU5TVVJMUmVzcG9uc2VTdGF0dXNMaW5lKG1f bnNSZXNwb25zZS5nZXQoKSkpOwotICAgICAgICAgICAgaWYgKGh0dHBTdGF0dXNMaW5lKQorICAg ICAgICAgICAgaWYgKFJldGFpblB0cjxOU1N0cmluZz4gaHR0cFN0YXR1c0xpbmUgPSBhZG9wdE5T KHdrQ29weU5TVVJMUmVzcG9uc2VTdGF0dXNMaW5lKGh0dHBSZXNwb25zZSkpKQogICAgICAgICAg ICAgICAgIG1faHR0cFN0YXR1c1RleHQgPSBleHRyYWN0UmVhc29uUGhyYXNlRnJvbUhUVFBTdGF0 dXNMaW5lKGh0dHBTdGF0dXNMaW5lLmdldCgpKTsKICAgICAgICAgICAgIGVsc2UKLSAgICAgICAg ICAgICAgICBtX2h0dHBTdGF0dXNUZXh0ID0gIk9LIjsKKyAgICAgICAgICAgICAgICBtX2h0dHBT dGF0dXNUZXh0ID0gQXRvbWljU3RyaW5nKCJPSyIsIEF0b21pY1N0cmluZzo6Q29uc3RydWN0RnJv bUxpdGVyYWwpOwogCiAgICAgICAgICAgICBOU0RpY3Rpb25hcnkgKmhlYWRlcnMgPSBbaHR0cFJl c3BvbnNlIGFsbEhlYWRlckZpZWxkc107Ci0gICAgICAgICAgICBOU0VudW1lcmF0b3IgKmUgPSBb aGVhZGVycyBrZXlFbnVtZXJhdG9yXTsKLSAgICAgICAgICAgIHdoaWxlIChOU1N0cmluZyAqbmFt ZSA9IFtlIG5leHRPYmplY3RdKQorICAgICAgICAgICAgZm9yIChOU1N0cmluZyAqbmFtZSBpbiBo ZWFkZXJzKQogICAgICAgICAgICAgICAgIG1faHR0cEhlYWRlckZpZWxkcy5zZXQoU3RyaW5nKG5h bWUpLCBbaGVhZGVycyBvYmplY3RGb3JLZXk6bmFtZV0pOwogICAgICAgICAgICAgCiAgICAgICAg ICAgICBbcG9vbCBkcmFpbl07Cg== 239879 2014-10-15 11:16:28 -0700 2014-10-15 17:10:02 -0700 Follow-up patch for nits. 137721_platformLazyInit_part2.patch text/plain 2382 cdumez ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZwppbmRleCBiNGYxNTdmLi5lOTMxNTk4IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29y ZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDUgKzEsMjEg QEAKIDIwMTQtMTAtMTUgIENocmlzIER1bWV6ICA8Y2R1bWV6QGFwcGxlLmNvbT4KIAorICAgICAg ICBbTWFjXSBGaXggaW5lZmZpY2llbmNpZXMgaW4gUmVzb3VyY2VSZXNwb25zZTo6cGxhdGZvcm1M YXp5SW5pdChJbml0TGV2ZWwpIC0gUGFydCAyCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD0xMzc3MjEKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkg KE9PUFMhKS4KKworICAgICAgICBGb2xsb3ctdXAgcGF0Y2ggdG8gcjE3NDcxNyBhZGRyZXNzaW5n IHJldmlldyBjb21tZW50cyBtYWRlIGFmdGVyIHRoZSBwYXRjaCBsYW5kZWQ6CisgICAgICAgIC0g VXNlIG1vZGVybiBDKysgbG9vcAorICAgICAgICAtIFJlbW92ZSBleHBsaWNpdCBjYWxscyB0byBT dHJpbmcoTlNTdHJpbmcqKSBjb25zdHJ1Y3RvcgorCisgICAgICAgIE5vIG5ldyB0ZXN0cywgbm8g bmV3IHRlc3RzLgorCisgICAgICAgICogcGxhdGZvcm0vbmV0d29yay9tYWMvUmVzb3VyY2VSZXNw b25zZU1hYy5tbToKKyAgICAgICAgKFdlYkNvcmU6OlJlc291cmNlUmVzcG9uc2U6OnBsYXRmb3Jt TGF6eUluaXQpOgorCisyMDE0LTEwLTE1ICBDaHJpcyBEdW1leiAgPGNkdW1lekBhcHBsZS5jb20+ CisKICAgICAgICAgW01hY10gVXNlIENGRGljdGlvbmFyeUNvbnRhaW5zS2V5KCkgaW4gSW1hZ2VT b3VyY2U6OmlzU2l6ZUF2YWlsYWJsZSgpCiAgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3Jn L3Nob3dfYnVnLmNnaT9pZD0xMzc3MjMKIApkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGxh dGZvcm0vbmV0d29yay9tYWMvUmVzb3VyY2VSZXNwb25zZU1hYy5tbSBiL1NvdXJjZS9XZWJDb3Jl L3BsYXRmb3JtL25ldHdvcmsvbWFjL1Jlc291cmNlUmVzcG9uc2VNYWMubW0KaW5kZXggNGU5N2Ez NS4uYjIzMTBiOCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vbmV0d29yay9t YWMvUmVzb3VyY2VSZXNwb25zZU1hYy5tbQorKysgYi9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9u ZXR3b3JrL21hYy9SZXNvdXJjZVJlc3BvbnNlTWFjLm1tCkBAIC0xMzgsOSArMTM4LDkgQEAgdm9p ZCBSZXNvdXJjZVJlc3BvbnNlOjpwbGF0Zm9ybUxhenlJbml0KEluaXRMZXZlbCBpbml0TGV2ZWwp CiAgICAgICAgICAgICAKICAgICAgICAgICAgIGlmIChpbml0TGV2ZWwgPCBBbGxGaWVsZHMpIHsK ICAgICAgICAgICAgICAgICBOU0RpY3Rpb25hcnkgKmhlYWRlcnMgPSBbaHR0cFJlc3BvbnNlIGFs bEhlYWRlckZpZWxkc107Ci0gICAgICAgICAgICAgICAgZm9yICh1bnNpZ25lZCBpID0gMDsgaSA8 IFdURl9BUlJBWV9MRU5HVEgoY29tbW9uSGVhZGVyRmllbGRzKTsgKytpKSB7Ci0gICAgICAgICAg ICAgICAgICAgIGlmIChOU1N0cmluZyogaGVhZGVyVmFsdWUgPSBbaGVhZGVycyBvYmplY3RGb3JL ZXk6Y29tbW9uSGVhZGVyRmllbGRzW2ldXSkKLSAgICAgICAgICAgICAgICAgICAgICAgIG1faHR0 cEhlYWRlckZpZWxkcy5zZXQoU3RyaW5nKGNvbW1vbkhlYWRlckZpZWxkc1tpXSksIGhlYWRlclZh bHVlKTsKKyAgICAgICAgICAgICAgICBmb3IgKE5TU3RyaW5nICpuYW1lIDogY29tbW9uSGVhZGVy RmllbGRzKSB7CisgICAgICAgICAgICAgICAgICAgIGlmIChOU1N0cmluZyogaGVhZGVyVmFsdWUg PSBbaGVhZGVycyBvYmplY3RGb3JLZXk6bmFtZV0pCisgICAgICAgICAgICAgICAgICAgICAgICBt X2h0dHBIZWFkZXJGaWVsZHMuc2V0KG5hbWUsIGhlYWRlclZhbHVlKTsKICAgICAgICAgICAgICAg ICB9CiAgICAgICAgICAgICB9CiAgICAgICAgIH0gZWxzZQpAQCAtMTYxLDcgKzE2MSw3IEBAIHZv aWQgUmVzb3VyY2VSZXNwb25zZTo6cGxhdGZvcm1MYXp5SW5pdChJbml0TGV2ZWwgaW5pdExldmVs KQogCiAgICAgICAgICAgICBOU0RpY3Rpb25hcnkgKmhlYWRlcnMgPSBbaHR0cFJlc3BvbnNlIGFs bEhlYWRlckZpZWxkc107CiAgICAgICAgICAgICBmb3IgKE5TU3RyaW5nICpuYW1lIGluIGhlYWRl cnMpCi0gICAgICAgICAgICAgICAgbV9odHRwSGVhZGVyRmllbGRzLnNldChTdHJpbmcobmFtZSks IFtoZWFkZXJzIG9iamVjdEZvcktleTpuYW1lXSk7CisgICAgICAgICAgICAgICAgbV9odHRwSGVh ZGVyRmllbGRzLnNldChuYW1lLCBbaGVhZGVycyBvYmplY3RGb3JLZXk6bmFtZV0pOwogICAgICAg ICAgICAgCiAgICAgICAgICAgICBbcG9vbCBkcmFpbl07CiAgICAgICAgIH0K