129212 2014-02-22 11:08:59 -0800 Refine DFG+FTL inlining and compilation limits 2014-02-23 13:48:57 -0800 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) All All RESOLVED FIXED P2 Normal --- 112840 1 fpizlo fpizlo atrick barraclough ggaren mark.lam mhahnenberg mmirman msaboff nrotem oliver sam oldest_to_newest 983617 0 fpizlo 2014-02-22 11:08:59 -0800 Patch forthcoming. 983620 1 224978 fpizlo 2014-02-22 11:13:31 -0800 Created attachment 224978 the patch 983701 2 224978 mhahnenberg 2014-02-23 08:40:08 -0800 Comment on attachment 224978 the patch r=me 983705 3 224978 ggaren 2014-02-23 09:05:26 -0800 Comment on attachment 224978 the patch View in context: https://bugs.webkit.org/attachment.cgi?id=224978&action=review > Source/JavaScriptCore/bytecode/CodeBlock.cpp:2793 > + dataLog(" Marking SABI because caller is too large.\n"); Don't you mean "Marking !SABI"? > Source/JavaScriptCore/runtime/Options.h:188 > + /* Maximum size of a caller for enabling inlining. This is purely to protect us */\ > + /* super long compiles. */\ "from super long compiles"? 983709 4 224978 ggaren 2014-02-23 09:17:36 -0800 Comment on attachment 224978 the patch GCC has a "caller too big" heuristic for inlining, and back when we compiled with GCC it caused very bad performance pathologies. A lot of critical functions in WebCore/JavaScriptCore are indeed big -- HTML parser, CSS parser, JavaScript parser, Interpreter::execute when it was written in C -- and the "caller too big" heuristic forced trivial functions like JSValue::isCell() and StringImpl::isAtomic() not to inline, even though inlining them is a pure win, reducing both code size and compile time. When those pathologies present, they're also horrible to debug, since you can add an innocuous line of code somewhere in a function's slow path, and mysteriously make it 2X slower. If "SABI" doesn't actually mean "should always be inlined", and instead means "should maybe inline depending on caller's size", then I think it needs a better name, and we need to introduce a new "SABI" that truly means "I'm so small that I should always inline". 983715 5 fpizlo 2014-02-23 10:00:10 -0800 (In reply to comment #4) > (From update of attachment 224978 [details]) > GCC has a "caller too big" heuristic for inlining, and back when we compiled with GCC it caused very bad performance pathologies. A lot of critical functions in WebCore/JavaScriptCore are indeed big -- HTML parser, CSS parser, JavaScript parser, Interpreter::execute when it was written in C -- and the "caller too big" heuristic forced trivial functions like JSValue::isCell() and StringImpl::isAtomic() not to inline, even though inlining them is a pure win, reducing both code size and compile time. > > When those pathologies present, they're also horrible to debug, since you can add an innocuous line of code somewhere in a function's slow path, and mysteriously make it 2X slower. I'm well aware of these performance pathologies and GCC is not the only compiler that has had this issue in its history. But, horrible-to-debug performance pathologies are better than chain-crashing because LLVM ran out of memory. If we ever suspect that the performance of a program is bad because of these heuristics, we should loosen the heuristics and see if we get a speed-up. > > If "SABI" doesn't actually mean "should always be inlined", and instead means "should maybe inline depending on caller's size", then I think it needs a better name, and we need to introduce a new "SABI" that truly means "I'm so small that I should always inline". I think you're confusing two different heuristics. There is the too-big-to-inline-into heuristic, which has nothing to do with SABI; and then there's SABI, which doesn't mean "I'm so small that I should always inline" - it means that we believe that based on current heuristics, all of the callers of this function have either already been compiled with DFG/FTL and have inlined it, or they will be compiled with DFG/FTL and will inline it. Notice that we mark !SABI if we see you're being called from a too-big-to-inline-into function because we can be pretty sure that this function will never inline anything. 983725 6 fpizlo 2014-02-23 10:39:15 -0800 (In reply to comment #3) > (From update of attachment 224978 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=224978&action=review > > > Source/JavaScriptCore/bytecode/CodeBlock.cpp:2793 > > + dataLog(" Marking SABI because caller is too large.\n"); > > Don't you mean "Marking !SABI"? Yes, fixed! Changed to "Clearing SABI". > > > Source/JavaScriptCore/runtime/Options.h:188 > > + /* Maximum size of a caller for enabling inlining. This is purely to protect us */\ > > + /* super long compiles. */\ > > "from super long compiles"? Yes, fixed! Thanks! 983726 7 fpizlo 2014-02-23 10:44:06 -0800 Landed in http://trac.webkit.org/changeset/164558 983734 8 ggaren 2014-02-23 12:52:11 -0800 > I'm well aware of these performance pathologies and GCC is not the only compiler that has had this issue in its history. But, horrible-to-debug performance pathologies are better than chain-crashing because LLVM ran out of memory. Won't maximumOptimizationCandidateInstructionCount protect us from chain-crashing? Assuming that a function is net-win to inline, inlining it will never make the difference between crashing and not. > If we ever suspect that the performance of a program is bad because of these heuristics, we should loosen the heuristics and see if we get a speed-up. Given that we both agree, based on lots of experience with existing programs and compilers, that real programs do achieve bad performance because of these heuristics, I don't think it makes sense to treat this problem as a theoretical one that might never happen, or that needs more investigation. Instead, I think we should implement the solution that LLVM implemented: If a function is small/trivial enough, we should allow it to inline always, even if its caller is large. > I think you're confusing two different heuristics. Yes, I guess I am. (1) I propose that we have a real concept of "should always be inlined" that means "I should always be inlined because it is always net profitable to do so regardless of caller size". (2) We have an existing concept named "should always be inlined" which means something more like "I predict that I will usually be inlined before optimizing me is necessary". 983745 9 fpizlo 2014-02-23 13:48:57 -0800 (In reply to comment #8) > > I'm well aware of these performance pathologies and GCC is not the only compiler that has had this issue in its history. But, horrible-to-debug performance pathologies are better than chain-crashing because LLVM ran out of memory. > > Won't maximumOptimizationCandidateInstructionCount protect us from chain-crashing? Assuming that a function is net-win to inline, inlining it will never make the difference between crashing and not. OK - before we proceed further with this thread, let's make some things clear: - Inlining heuristics are not the longest pole in the tent right now. Every time that I play with the thresholds, I see negligible performance differences. The purpose of maximumInliningCallerSize is to protect us from a code size and compile time pathology that I saw on real JS code, and I set it to the smallest value that didn't adversely affect performance on the benchmarks. - Your proposals require substantially more work than this 6KB patch. It's possible we may do it at some later time, but it won't help us meet our current goals because after this patch, inlining is no longer the longest pole in the tent. - This 6KB patch is a net progression and doesn't hurt any benchmark that we have in our repertoire. Now that I've gotten that out of the way, to answer your questin about maximumOptimizationCandidateInstructionCount: Currently, if the caller is small enough, we do inlining even if the caller is larger than the size of a callsite. That size threshold was derived from doing a grid search and optimizing performance on a bunch of benchmarks, so it's clear that we definitely want to continue to allow inlining even if it increases code size, but that of course also means that sometimes this code-size-increasing inliner must be disabled even if the caller was small enough to compile and the callee otherwise met the inliner's heuristics. That's what maximumInliningCallerSize is for. If we give the inliner the ability to handle must-inline functions (i.e. functions that are estimated to be smaller than a callsite and therefore inlining them will not increase code size), we will still have to keep around a heuristic like maximumInliningCallerSize, but we will probably rename it to maximumCodeSizeIncreasingInliningCallerSize, and it will apply only to functions that are larger than a callsite but are otherwise inlineable based on our current rules. > > > If we ever suspect that the performance of a program is bad because of these heuristics, we should loosen the heuristics and see if we get a speed-up. > > Given that we both agree, based on lots of experience with existing programs and compilers, that real programs do achieve bad performance because of these heuristics, I don't think it makes sense to treat this problem as a theoretical one that might never happen, or that needs more investigation. It's true that if our inliner was a lot more sophisticated, then the maximumInliningCallerSize limit would either be completely unnecessary or it would go by a different name. But for now, we need that limit, and we will probably continue to need that limit for the foreseeable future. > > Instead, I think we should implement the solution that LLVM implemented: If a function is small/trivial enough, we should allow it to inline always, even if its caller is large. Comparing LLVM's inliner and our inliner is like comparing apples and oranges. - LLVM's inliner runs after LLVM has run a lot of its optimization pipeline on both the caller and the callee. Hence LLVM has a much better estimate of the callee's size. By contrast, for a typical callsite, at the time that our inliner makes its decision, we only see the callee's bytecode and we have to estimate size from that. Bytecode isn't a good starting point for making precise code size estimates. This is probably one of the reasons why our current thresholds often allow inlining that increases code size - we just don't have a good way of predicting whether code size increased will actually happen. - LLVM has a detailed cost model for predicting the size and performance of each LLVM instruction. It's true that after a lot of work we could probably derive such a cost model for DFG IR, but we haven't done it yet. I can understand that it's tempting to argue that we should just pick up some heuristics from LLVM and drop them into the DFG, but we need to understand that LLVM's heuristics are architected around a radically different inliner - one that sees a hell of a lot more static information. To just reuse LLVM's inlining heuristics we would need to: - Change our inliner to see the callee's optimized DFG IR as an input instead of using bytecode. This would be a huge rewrite of the inliner and right now I can't think of a way of doing this without regressing memory use. - Add a cost model to DFG IR. We currently have no such model. For example, a GetById(Untyped:) is ~10-20x bigger than an ArithAdd(Int32:, Int32:, Unchecked) but right now there is no way to *know* this and adding this knowledge is probably >3000 lines of code. Of course, it's theoretically possible that you could build heuristics that are as good as LLVM's in the average but that don't rely on seeing optimized IR of the caller or having a super precise cost model. But whatever you do it'll be more work than this patch and even if you did all of that work, you'd still have most of the current heuristics as hard fall-backs. For example, it's very profitable to have a quick "definitely don't inline this function" rule based on that function's bytecode size, since you can get that in O(1) time and it filters out a lot of obvious no-nos. Also, while it's true that eventually we might set maximumInliningCallerSize to be larger than maximumFTLCandidateInstructionCount or maximumOptimizationCandidateInstructionCount - effectively obviating the need for that heuristic - we're definitely not there yet and it won't happen for a while. > > > I think you're confusing two different heuristics. > > Yes, I guess I am. > > (1) I propose that we have a real concept of "should always be inlined" that means "I should always be inlined because it is always net profitable to do so regardless of caller size". I usually call this "must inline". > > (2) We have an existing concept named "should always be inlined" which means something more like "I predict that I will usually be inlined before optimizing me is necessary". I would summarize my point as: on all of the benchmarks we track, from what I can tell based on profiling, inlining is good enough that the path of least resistance to getting further speed-ups probably involves leaving the inliner alone. Inlining heuristics are a black art and you can always do better, and it's great that we have ideas for how to improve it. But it shouldn't be a top priority. 224978 2014-02-22 11:13:31 -0800 2014-02-23 09:17:36 -0800 the patch blah.patch text/plain 6704 fpizlo SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291 cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gMTY0NTQ3KQorKysgU291cmNl L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDMyIEBA CisyMDE0LTAyLTIyICBGaWxpcCBQaXpsbyAgPGZwaXpsb0BhcHBsZS5jb20+CisKKyAgICAgICAg UmVmaW5lIERGRytGVEwgaW5saW5pbmcgYW5kIGNvbXBpbGF0aW9uIGxpbWl0cworICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTI5MjEyCisKKyAgICAgICAg UmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisgICAgICAgIAorICAgICAgICBBbGxvdyBsYXJn ZXIgZnVuY3Rpb25zIHRvIGJlIERGRy1jb21waWxlZC4gSW5zdGl0dXRlIGEgbGltaXQgb24gRlRM IGNvbXBpbGF0aW9uLAorICAgICAgICBhbmQgc2V0IHRoYXQgbGltaXQgcXVpdGUgaGlnaC4gSW5z dGl0dXRlIGEgbGltaXQgb24gaW5saW5pbmctaW50by4gVGhlIGlkZWEgaGVyZSBpcworICAgICAg ICB0aGF0IGxhcmdlIGZ1bmN0aW9ucyB0ZW5kIHRvIGJlIGF1dG9nZW5lcmF0ZWQsIGFuZCBjb2Rl IGdlbmVyYXRvcnMgbGlrZSBlbXNjcmlwdGVuCisgICAgICAgIGFwcGVhciB0byBsZWF2ZSBmZXcg aW5saW5pbmcgb3Bwb3J0dW5pdGllcyBhbnl3YXkuIEFsc28sIHdlIGRvbid0IHdhbnQgdGhlIGNv ZGUKKyAgICAgICAgc2l6ZSBleHBsb3Npb24gdGhhdCB3ZSB3b3VsZCByaXNrIGlmIHdlIGFsbG93 ZWQgY29tcGlsYXRpb24gb2YgYSBsYXJnZSBmdW5jdGlvbiBhbmQKKyAgICAgICAgdGhlbiBpbmxp bmVkIGEgdG9uIG9mIHN0dWZmIGludG8gaXQuCisgICAgICAgIAorICAgICAgICBUaGlzIGlzIGEg MC41JSBzcGVlZC11cCBvbiBPY3RhbmUgdjIgYW5kIGFsbW9zdCBlbGltaW5hdGVzIHRoZSB0eXBl c2NyaXB0CisgICAgICAgIHJlZ3Jlc3Npb24uIFRoaXMgaXMgYSA5JSBzcGVlZC11cCBvbiBBc21C ZW5jaC4KKworICAgICAgICAqIGJ5dGVjb2RlL0NvZGVCbG9jay5jcHA6CisgICAgICAgIChKU0M6 OkNvZGVCbG9jazo6bm90aWNlSW5jb21pbmdDYWxsKToKKyAgICAgICAgKiBkZmcvREZHQnl0ZUNv ZGVQYXJzZXIuY3BwOgorICAgICAgICAoSlNDOjpERkc6OkJ5dGVDb2RlUGFyc2VyOjpoYW5kbGVJ bmxpbmluZyk6CisgICAgICAgICogZGZnL0RGR0NhcGFiaWxpdGllcy5oOgorICAgICAgICAoSlND OjpERkc6OmlzU21hbGxFbm91Z2hUb0lubGluZUNvZGVJbnRvKToKKyAgICAgICAgKiBmdGwvRlRM Q2FwYWJpbGl0aWVzLmNwcDoKKyAgICAgICAgKEpTQzo6RlRMOjpjYW5Db21waWxlKToKKyAgICAg ICAgKiBmdGwvRlRMU3RhdGUuaDoKKyAgICAgICAgKEpTQzo6RlRMOjpzaG91bGRTaG93RGlzYXNz ZW1ibHkpOgorICAgICAgICAqIHJ1bnRpbWUvT3B0aW9ucy5oOgorCiAyMDE0LTAyLTIxICBCcmVu dCBGdWxnaGFtICA8YmZ1bGdoYW1AYXBwbGUuY29tPgogCiAgICAgICAgIEV4dGVuZCBtZWRpYSBz dXBwb3J0IGZvciBXZWJWVFQgc291cmNlcwpJbmRleDogU291cmNlL0phdmFTY3JpcHRDb3JlL2J5 dGVjb2RlL0NvZGVCbG9jay5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL0phdmFTY3JpcHRDb3Jl L2J5dGVjb2RlL0NvZGVCbG9jay5jcHAJKHJldmlzaW9uIDE2NDQ5MykKKysrIFNvdXJjZS9KYXZh U2NyaXB0Q29yZS9ieXRlY29kZS9Db2RlQmxvY2suY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0yNzg2 LDYgKzI3ODYsMTMgQEAgdm9pZCBDb2RlQmxvY2s6Om5vdGljZUluY29taW5nQ2FsbChFeGVjUwog CiAgICAgaWYgKCFjYW5JbmxpbmUobV9jYXBhYmlsaXR5TGV2ZWxTdGF0ZSkpCiAgICAgICAgIHJl dHVybjsKKyAgICAKKyAgICBpZiAoIURGRzo6aXNTbWFsbEVub3VnaFRvSW5saW5lQ29kZUludG8o Y2FsbGVyQ29kZUJsb2NrKSkgeworICAgICAgICBtX3Nob3VsZEFsd2F5c0JlSW5saW5lZCA9IGZh bHNlOworICAgICAgICBpZiAoT3B0aW9uczo6dmVyYm9zZUNhbGxMaW5rKCkpCisgICAgICAgICAg ICBkYXRhTG9nKCIgICAgTWFya2luZyBTQUJJIGJlY2F1c2UgY2FsbGVyIGlzIHRvbyBsYXJnZS5c biIpOworICAgICAgICByZXR1cm47CisgICAgfQogCiAgICAgaWYgKGNhbGxlckNvZGVCbG9jay0+ aml0VHlwZSgpID09IEpJVENvZGU6OkludGVycHJldGVyVGh1bmspIHsKICAgICAgICAgLy8gSWYg dGhlIGNhbGxlciBpcyBzdGlsbCBpbiB0aGUgaW50ZXJwcmV0ZXIsIHRoZW4gd2UgY2FuJ3QgZXhw ZWN0IGlubGluaW5nIHRvCkluZGV4OiBTb3VyY2UvSmF2YVNjcmlwdENvcmUvZGZnL0RGR0J5dGVD b2RlUGFyc2VyLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvSmF2YVNjcmlwdENvcmUvZGZnL0RG R0J5dGVDb2RlUGFyc2VyLmNwcAkocmV2aXNpb24gMTY0NDkzKQorKysgU291cmNlL0phdmFTY3Jp cHRDb3JlL2RmZy9ERkdCeXRlQ29kZVBhcnNlci5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTEzMTYs NiArMTMxNiwxNiBAQCBib29sIEJ5dGVDb2RlUGFyc2VyOjpoYW5kbGVJbmxpbmluZyhOb2RlCiAg ICAgICAgIHJldHVybiBmYWxzZTsKICAgICB9CiAgICAgCisgICAgLy8gQ2hlY2sgaWYgdGhlIGNh bGxlciBpcyBhbHJlYWR5IHRvbyBsYXJnZS4gV2UgZG8gdGhpcyBjaGVjayBoZXJlIGJlY2F1c2Ug dGhhdCdzIGp1c3QKKyAgICAvLyB3aGVyZSB3ZSBoYXBwZW4gdG8gYWxzbyBoYXZlIHRoZSBjYWxs ZWUncyBjb2RlIGJsb2NrLCBhbmQgd2Ugd2FudCB0aGF0IGZvciB0aGUKKyAgICAvLyBwdXJwb3Nl IG9mIHVuc2V0dGluZyBTQUJJLgorICAgIGlmICghaXNTbWFsbEVub3VnaFRvSW5saW5lQ29kZUlu dG8obV9jb2RlQmxvY2spKSB7CisgICAgICAgIGNvZGVCbG9jay0+bV9zaG91bGRBbHdheXNCZUlu bGluZWQgPSBmYWxzZTsKKyAgICAgICAgaWYgKHZlcmJvc2UpCisgICAgICAgICAgICBkYXRhTG9n KCIgICAgRmFpbGluZyBiZWNhdXNlIHRoZSBjYWxsZXIgaXMgdG9vIGxhcmdlLlxuIik7CisgICAg ICAgIHJldHVybiBmYWxzZTsKKyAgICB9CisgICAgCiAgICAgLy8gRklYTUU6IHRoaXMgc2hvdWxk IGJlIGJldHRlciBhdCBwcmVkaWN0aW5nIGhvdyBtdWNoIGJsb2F0IHdlIHdpbGwgaW50cm9kdWNl IGJ5IGlubGluaW5nCiAgICAgLy8gdGhpcyBmdW5jdGlvbi4KICAgICAvLyBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTI3NjI3CkluZGV4OiBTb3VyY2UvSmF2YVNjcmlw dENvcmUvZGZnL0RGR0NhcGFiaWxpdGllcy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2Ny aXB0Q29yZS9kZmcvREZHQ2FwYWJpbGl0aWVzLmgJKHJldmlzaW9uIDE2NDQ5MykKKysrIFNvdXJj ZS9KYXZhU2NyaXB0Q29yZS9kZmcvREZHQ2FwYWJpbGl0aWVzLmgJKHdvcmtpbmcgY29weSkKQEAg LTE0NCw2ICsxNDQsMTEgQEAgaW5saW5lIENhcGFiaWxpdHlMZXZlbCBpbmxpbmVGdW5jdGlvbkZv cgogICAgIHJldHVybiBpbmxpbmVGdW5jdGlvbkZvckNvbnN0cnVjdENhcGFiaWxpdHlMZXZlbChj b2RlQmxvY2spOwogfQogCitpbmxpbmUgYm9vbCBpc1NtYWxsRW5vdWdoVG9JbmxpbmVDb2RlSW50 byhDb2RlQmxvY2sqIGNvZGVCbG9jaykKK3sKKyAgICByZXR1cm4gY29kZUJsb2NrLT5pbnN0cnVj dGlvbkNvdW50KCkgPD0gT3B0aW9uczo6bWF4aW11bUlubGluaW5nQ2FsbGVyU2l6ZSgpOworfQor CiB9IH0gLy8gbmFtZXNwYWNlIEpTQzo6REZHCiAKICNlbmRpZiAvLyBERkdDYXBhYmlsaXRpZXNf aApJbmRleDogU291cmNlL0phdmFTY3JpcHRDb3JlL2Z0bC9GVExDYXBhYmlsaXRpZXMuY3BwCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9mdGwvRlRMQ2FwYWJpbGl0aWVzLmNw cAkocmV2aXNpb24gMTY0NDkzKQorKysgU291cmNlL0phdmFTY3JpcHRDb3JlL2Z0bC9GVExDYXBh YmlsaXRpZXMuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0yNzgsNiArMjc4LDEyIEBAIGlubGluZSBD YXBhYmlsaXR5TGV2ZWwgY2FuQ29tcGlsZShOb2RlKiAKIAogQ2FwYWJpbGl0eUxldmVsIGNhbkNv bXBpbGUoR3JhcGgmIGdyYXBoKQogeworICAgIGlmIChncmFwaC5tX2NvZGVCbG9jay0+aW5zdHJ1 Y3Rpb25Db3VudCgpID4gT3B0aW9uczo6bWF4aW11bUZUTENhbmRpZGF0ZUluc3RydWN0aW9uQ291 bnQoKSkgeworICAgICAgICBpZiAodmVyYm9zZUNhcGFiaWxpdGllcygpKQorICAgICAgICAgICAg ZGF0YUxvZygiRlRMIHJlamVjdGluZyAiLCAqZ3JhcGgubV9jb2RlQmxvY2ssICIgYmVjYXVzZSBp dCdzIHRvbyBiaWcuXG4iKTsKKyAgICAgICAgcmV0dXJuIENhbm5vdENvbXBpbGU7CisgICAgfQor ICAgIAogICAgIGlmIChncmFwaC5tX2NvZGVCbG9jay0+Y29kZVR5cGUoKSAhPSBGdW5jdGlvbkNv ZGUpIHsKICAgICAgICAgaWYgKHZlcmJvc2VDYXBhYmlsaXRpZXMoKSkKICAgICAgICAgICAgIGRh dGFMb2coIkZUTCByZWplY3RpbmcgIiwgKmdyYXBoLm1fY29kZUJsb2NrLCAiIGJlY2F1c2UgaXQg ZG9lc24ndCBiZWxvbmcgdG8gYSBmdW5jdGlvbi5cbiIpOwpJbmRleDogU291cmNlL0phdmFTY3Jp cHRDb3JlL2Z0bC9GVExTdGF0ZS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0Q29y ZS9mdGwvRlRMU3RhdGUuaAkocmV2aXNpb24gMTY0NDkzKQorKysgU291cmNlL0phdmFTY3JpcHRD b3JlL2Z0bC9GVExTdGF0ZS5oCSh3b3JraW5nIGNvcHkpCkBAIC00Niw3ICs0Niw3IEBAIGlubGlu ZSBib29sIHZlcmJvc2VDb21waWxhdGlvbkVuYWJsZWQoKQogICAgIHJldHVybiBERkc6OnZlcmJv c2VDb21waWxhdGlvbkVuYWJsZWQoREZHOjpGVExNb2RlKTsKIH0KIAotaW5saW5lIGJvb2wgc2hv d0Rpc2Fzc2VtYmx5KCkKK2lubGluZSBib29sIHNob3VsZFNob3dEaXNhc3NlbWJseSgpCiB7CiAg ICAgcmV0dXJuIERGRzo6c2hvdWxkU2hvd0Rpc2Fzc2VtYmx5KERGRzo6RlRMTW9kZSk7CiB9Cklu ZGV4OiBTb3VyY2UvSmF2YVNjcmlwdENvcmUvcnVudGltZS9PcHRpb25zLmgKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gU291cmNlL0phdmFTY3JpcHRDb3JlL3J1bnRpbWUvT3B0aW9ucy5oCShyZXZpc2lvbiAxNjQ0 OTMpCisrKyBTb3VyY2UvSmF2YVNjcmlwdENvcmUvcnVudGltZS9PcHRpb25zLmgJKHdvcmtpbmcg Y29weSkKQEAgLTE3MCwxOCArMTcwLDI0IEBAIHR5cGVkZWYgT3B0aW9uUmFuZ2Ugb3B0aW9uUmFu Z2U7CiAgICAgXAogICAgIHYoYm9vbCwgYnJlYWtPblRocm93LCBmYWxzZSkgXAogICAgIFwKLSAg ICB2KHVuc2lnbmVkLCBtYXhpbXVtT3B0aW1pemF0aW9uQ2FuZGlkYXRlSW5zdHJ1Y3Rpb25Db3Vu dCwgMTAwMDApIFwKKyAgICB2KHVuc2lnbmVkLCBtYXhpbXVtT3B0aW1pemF0aW9uQ2FuZGlkYXRl SW5zdHJ1Y3Rpb25Db3VudCwgMTAwMDAwKSBcCiAgICAgXAogICAgIHYodW5zaWduZWQsIG1heGlt dW1GdW5jdGlvbkZvckNhbGxJbmxpbmVDYW5kaWRhdGVJbnN0cnVjdGlvbkNvdW50LCAxODApIFwK ICAgICB2KHVuc2lnbmVkLCBtYXhpbXVtRnVuY3Rpb25Gb3JDbG9zdXJlQ2FsbElubGluZUNhbmRp ZGF0ZUluc3RydWN0aW9uQ291bnQsIDEwMCkgXAogICAgIHYodW5zaWduZWQsIG1heGltdW1GdW5j dGlvbkZvckNvbnN0cnVjdElubGluZUNhbmRpZGF0ZUluc3RydWN0aW9uQ291bnQsIDEwMCkgXAog ICAgIFwKKyAgICB2KHVuc2lnbmVkLCBtYXhpbXVtRlRMQ2FuZGlkYXRlSW5zdHJ1Y3Rpb25Db3Vu dCwgMjAwMDApIFwKKyAgICBcCiAgICAgLyogRGVwdGggb2YgaW5saW5lIHN0YWNrLCBzbyAxID0g bm8gaW5saW5pbmcsIDIgPSBvbmUgbGV2ZWwsIGV0Yy4gKi8gXAogICAgIHYodW5zaWduZWQsIG1h eGltdW1JbmxpbmluZ0RlcHRoLCA1KSBcCiAgICAgdih1bnNpZ25lZCwgbWF4aW11bUlubGluaW5n UmVjdXJzaW9uLCAyKSBcCiAgICAgdih1bnNpZ25lZCwgbWF4aW11bUlubGluaW5nRGVwdGhGb3JN dXN0SW5saW5lLCA3KSBcCiAgICAgdih1bnNpZ25lZCwgbWF4aW11bUlubGluaW5nUmVjdXJzaW9u Rm9yTXVzdElubGluZSwgMykgXAogICAgIFwKKyAgICAvKiBNYXhpbXVtIHNpemUgb2YgYSBjYWxs ZXIgZm9yIGVuYWJsaW5nIGlubGluaW5nLiBUaGlzIGlzIHB1cmVseSB0byBwcm90ZWN0IHVzICov XAorICAgIC8qIHN1cGVyIGxvbmcgY29tcGlsZXMuICovXAorICAgIHYodW5zaWduZWQsIG1heGlt dW1JbmxpbmluZ0NhbGxlclNpemUsIDEwMDAwKSBcCisgICAgXAogICAgIHYoYm9vbCwgZW5hYmxl UG9seXZhcmlhbnRDYWxsSW5saW5pbmcsIHRydWUpIFwKICAgICB2KGJvb2wsIGVuYWJsZVBvbHl2 YXJpYW50QnlJZElubGluaW5nLCB0cnVlKSBcCiAgICAgXAo=