30681 2009-10-22 10:42:05 -0700 [Symbian] JS Date operations very slow due to flaky POSIX date/time implementation 2010-05-05 09:32:06 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) S60 Hardware Other RESOLVED LATER P2 Normal --- 27065 0 s.mathur webkit-unassigned darin eric hausmann koivisto koshuin laszlo.gombos mjs webkit.review.bot oldest_to_newest 156923 0 s.mathur 2009-10-22 10:42:05 -0700 Bypass use of POSIX APIs in Date related operation and use Symbian OS APIs directly. I am preparing a small patch for getUTCOffset() and getDSTOffset() in JavascriptCore/WTF/DateMath.cpp that only affects Symbian platform. The current implementation of the above functions uses Symbian's PIPS (standard C implementation) which works too slowly when arbitrary date/time are given to it (due to parsing of historical TimeZone databases and more) . Patch follows soon. 156979 1 koshuin 2009-10-22 12:51:49 -0700 Hold this a bit. I'll check tomorrow, but I have a gut feeling that we changed the time functions In Qt not to use Open C but use Symbian APIs instead. We have the ECMA/Date tests disabled for Embedded Linux and Symbian as HW targets will fail due to slow execution time. 156983 2 s.mathur 2009-10-22 13:03:07 -0700 (In reply to comment #1) > Hold this a bit. I'll check tomorrow, but I have a gut feeling that we changed > the time functions In Qt not to use Open C but use Symbian APIs instead. We > have the ECMA/Date tests disabled for Embedded Linux and Symbian as HW targets > will fail due to slow execution time. Yes, I was also told that QDateTime and friends are being fixed up. :) But Javascript/WTF/DateMath.cpp is not using Qt at all for its Date/Time manipulation and goes straight to the POSIX APIs. You can check this yourself if you see who calls gregorianDateTimeToMS() and msToGregorianDateTime() in DateMath.cpp. 156986 3 41679 s.mathur 2009-10-22 13:08:52 -0700 Created attachment 41679 proposed patch Attaching patch. Two functions in DateMap.cpp use Symbian OS APIs directly for estimating Daylight savings correction. - Verified that ECMAscript Date tests all pass in Symbian emulator. 157121 4 koshuin 2009-10-23 01:36:16 -0700 Looks good for me. I checked and there is no overlap, infact we will change some of the functions to be more in line with this patch :) 157162 5 s.mathur 2009-10-23 08:09:35 -0700 Performance improvement: Sunspider date-totfe completes in 642ms with the above patch on an N97 vs. 12834ms previously using openC/PIPS implementation (the latter time is particularly bad because looking up timezone databases leads to lots of file I/O and client-server IPC on Symbian OS) 157185 6 s.mathur 2009-10-23 11:00:24 -0700 Corrected numbers: 5111ms for both date tests in Sunspider after the patch, 26682ms before. So about 5x faster. 157636 7 41679 darin 2009-10-25 16:31:55 -0700 Comment on attachment 41679 proposed patch I don't see how this could be right. I'll try to review later when I have more time, but this seems obviously wrong on my first reading. 158006 8 41679 koivisto 2009-10-26 16:17:09 -0700 Comment on attachment 41679 proposed patch Right, seems that this would trivially break getUTCOffset() by making it include DST correction. Not all callpaths automatically add the DST offset later. If Qt has better implementation, you could just switch to those (from the posix ones, with appropriate ifdefs). 158054 9 s.mathur 2009-10-26 18:19:34 -0700 Antti, thanks for your time and review comments. My clarifications are below: (In reply to comment #8) > (From update of attachment 41679 [details]) > Right, seems that this would trivially break getUTCOffset() by making it > include DST correction. Not all callpaths automatically add the DST offset > later. a) getUTCOffset() is only called from two functions in the same file: gregorianDateTimeToMS() and its inverse gregorianDateTimeToMS(). It is called from nowhere else for any port. In both places it is added to getDSTOffset(). I have changed both, so that their sum is consistent. b) The reason getUTCOffset() and getDSTOffset() always go together is because of the ECMAscript spec being written that way. The code mirrors the spec very nicely. http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf Section 15.9.1.9 describes the only place in the EMCA spec where LocalTZA and DaylightSavingsTA are used. They are added to each other. DaylightSavingsTA == getDSTOffset() , and LocalTZA == getDSTOffset(). > If Qt has better implementation, you could just switch to those (from the posix > ones, with appropriate ifdefs). c) I am hesitent to add Qt dependecy to Javascript/WTF/* because this code is entirely Qt-unware. It also use C/C++ primitive types like double all over the place, so any work to introduce something like qreal and other Qt baggage would be quite intrusive and might make the code less readable for other ports. Thanks again for your time and help! 158639 10 koivisto 2009-10-28 11:00:00 -0700 (In reply to comment #9) > a) getUTCOffset() is only called from two functions in the same file: > gregorianDateTimeToMS() and its inverse gregorianDateTimeToMS(). It is called > from nowhere else for any port. In both places it is added to getDSTOffset(). I > have changed both, so that their sum is consistent. At least a GregorianDateTime constructor in DateMath.h calls getUTCOffset() and expects it not have DST included. Anyone could add mode code that relies on getting the correct values from these functions. If there truly is no valid reason to get UTC and DST offsets separately then there probably should be only one function for returning the combined value. > c) I am hesitent to add Qt dependecy to Javascript/WTF/* because this code is > entirely Qt-unware. It also use C/C++ primitive types like double all over the > place, so any work to introduce something like qreal and other Qt baggage would > be quite intrusive and might make the code less readable for other ports. > > Thanks again for your time and help! You could probably put all Qt calls to a single file that does not expose Qt to the rest of the JSC. But you are right that avoiding the dependency is probably good idea if it does not exist already. 159459 11 s.mathur 2009-10-30 14:42:24 -0700 (In reply to comment #10) > At least a GregorianDateTime constructor in DateMath.h calls getUTCOffset() and > expects it not have DST included. Anyone could add mode code that relies on > getting the correct values from these functions. > If there truly is no valid reason to get UTC and DST offsets separately then > there probably should be only one function for returning the combined value. My bad, I missed DateMath.h. That GregorianDateTime c'tor is also adding a presumed DST offset of 1 hour there too, so I think I will make a patch that will prevent getUTCOffset() from being called by itself and wrap it all cleanly. Thanks Antti! 159718 12 hausmann 2009-11-01 19:52:20 -0800 (In reply to comment #9) > > If Qt has better implementation, you could just switch to those (from the posix > > ones, with appropriate ifdefs). > > c) I am hesitent to add Qt dependecy to Javascript/WTF/* because this code is > entirely Qt-unware. It also use C/C++ primitive types like double all over the > place, so any work to introduce something like qreal and other Qt baggage would > be quite intrusive and might make the code less readable for other ports. I don't think there's a problem using Qt functions in JavaScriptCore/WTF, we're doing that all over the place already. On the other hand your patch is realtively simple, too :) If it makes the patch easier and of course the code faster I'd say don't hesitate with using Qt functions there. It might also help to get more consistent behaviour across all Qt ports. 168379 13 44235 koshuin 2009-12-03 05:53:27 -0800 Created attachment 44235 another fix Added version that accounts for DST changes. DST is checked from timezone server on Symbian. 168451 14 s.mathur 2009-12-03 10:33:27 -0800 (In reply to comment #13) > Created an attachment (id=44235) [details] > another fix > > Added version that accounts for DST changes. DST is checked from timezone > server on Symbian. Janne, I am sorry but this is not good performance-wise. As you probably know client<->server communication in Symbian is a very slow process that requires a context-switch for each API call. And that's just part of the problem, since the concerete implementations of Connect(), DoWork(), Close() are time consuming by themselves [1]. So use of 2 Connect(), 2 Close() , and 2 TZ server API calls is not acceptable in speed critical code like JSC's Date/time implementation. Did you get the chance to time this on an N97 using Sunpsider date tests? On a related front, I previously noticed in reading the ECMAscript spec [Comment #9] that it's flexible about how an implementation does DST isolation. My understanding is that as long as the (functional) compliance tests pass, some liberties can be taken. If anyone disagrees, please comment. Therefore, another plan of attack _might_ be .. Patch 1: Remove the use of getUTCOffset() in the c'tor in DateMath.h and also makes sure that the affected member variable isn't incorrectly used later on/has invalid data. IIRC, only some ports use that member variable. Patch 2: Follow the suggestion in Comment #10 about "one function that returns a combined (sum) value" of getUTCOffset() + getDSTOffset(). Then it would be easy to make that wrapper function use either a new flag HAVE_WEAKDSTISOLATION, or PLATFORM(SYMBIAN), or both to return the value returned by User::UTCoffset(). The advantage of the above approach is that it requires zero Symbian server API usage and hence will be as efficient as a port's Date code ought to be. The disadvantage is that the UTC offset is for the current time, not an arbitrary time in the past or future. But if the ECMAscript functional compliance tests pass, the latter shouldn't be a problem, IMHO. [1] Page 14-19 : http://www.symbianresources.com/tutorials/advanced/clientserver/Client-ServerFramework.pdf 168469 15 koshuin 2009-12-03 11:10:27 -0800 > context-switch for each API call. And that's just part of the problem, since > the concerete implementations of Connect(), DoWork(), Close() are time > consuming by themselves [1]. So use of 2 Connect(), 2 Close() , and 2 TZ > server API calls is not acceptable in speed critical code like JSC's Date/time > implementation. Did you get the chance to time this on an N97 using Sunpsider > date tests? Results from 5800 express music: date-format-tofte + format-xparb = date total Before 5543ms + 24228ms = 29772ms After 2386ms + 2534ms = 4921ms Have you actually checked Context Switch times on newer devices ? it is minimal. Here is context switch time from my E71: Inter-thread context switch: 6.270000 us / round-trip (100000 round trips in total) Inter-process context switch: 6.860000 us / round-trip (100000 round trips in total) 168510 16 s.mathur 2009-12-03 12:53:35 -0800 (In reply to comment #15) > Results from 5800 express music: > date-format-tofte + format-xparb = date total > > Before 5543ms + 24228ms = 29772ms > After 2386ms + 2534ms = 4921ms > Wow, in that case I eat my words. (Yes, I see FTC trace of .Connect(), Close() and server API calls almost every day and they are really slow). I will make a phone build using the patch, try it out and report back. Thanks! 168546 17 koshuin 2009-12-03 14:22:25 -0800 > Wow, in that case I eat my words. (Yes, I see FTC trace of .Connect(), Close() > and server API calls almost every day and they are really slow). > > I will make a phone build using the patch, try it out and report back. > Slow is relative, we are talking about seconds here :) FTC resolution is insane, I'm amazed by the tool. .Connect() would be really slow in case where server is not running and having to start the server process. I would assume TZ to be always running, could be wrong. Problem is that there really aren't other alternatives when using pure Symbian APIs. There is one call that could be made in TLocale but that is said to be deprecated in the header. And for Open C , I don't have their source code so I can't say what they are doing to spend so much time on those functions. Best alternative after all would be to fix Open C and leave datemath.cpp as is. Try it out and see what numbers you get. --- Measuring just the context switch doesn't really bare any meaning.. here is some more interesting numbers for this case. Notice the huge difference, this is what I was referring to. These numbers haven't been measured with FTC so they have some extra time from instrumentation. Nokia E61: Synchronous IPC function with one argument and result: 143,550000 us / call (20000 calls in total) Synchronous IPC function with buffer[32] argument read: 161,900000 us / call (20000 calls in total) Nokia E71: Synchronous IPC function with one argument and result: 7,550000 us / call (20000 calls in total) Synchronous IPC function with buffer[32] argument read: 13,250000 us / call (20000 calls in total) 170665 18 s.mathur 2009-12-11 03:09:12 -0800 (In reply to comment #17) > Slow is relative, we are talking about seconds here :) Indeed , _seconds_ . On a 434MhZ ARM11. ;) Anyways, I was able to verify that with your patch, the number on N97 was dramatically better than with the existing openC/PIPS release. Please feel free to open the patch for review when you are ready. 171138 19 hausmann 2009-12-12 16:16:02 -0800 (In reply to comment #13) > Created an attachment (id=44235) [details] > another fix > > Added version that accounts for DST changes. DST is checked from timezone > server on Symbian. Janne, the patch looks like it should be marked for review :) 171308 20 webkit.review.bot 2009-12-14 00:06:38 -0800 style-queue ran check-webkit-style on attachment 44235 without any errors. 171499 21 44235 eric 2009-12-14 12:20:32 -0800 Comment on attachment 44235 another fix It's unfortunate that this is abstracted via #ifdefs instead of functions. If we used functions then we could at some later date move those functions to another file. 175448 22 44235 koshuin 2009-12-28 23:37:18 -0800 Comment on attachment 44235 another fix Killed the patch. I've found out when doing making the same patch for Qt that 3.1/3.2/5.0 all have major differences in API for timezone server and would cause this patch to fail to compile on 3.1. Problem is that 3.1 version of the API cannot be used like this to get DST at all. Build variant for 3.1/3.2/5.0/future needs to be added if the code will stay on webkit side. I think datemath needs to call datetime as already suggested in the comments. 175457 23 koshuin 2009-12-28 23:50:32 -0800 I've also contacted Open C guys who promised to take a look at their performance of their posix time functions. 184156 24 koshuin 2010-01-24 22:06:22 -0800 (In reply to comment #23) > I've also contacted Open C guys who promised to take a look at their > performance of their posix time functions. Got a patch from Open C guys and testing it out. If it works out fine I guess we could close this issue. Problem is that the fix won't make it into their next release and I have no idea when newer release will be coming out. 187341 25 koshuin 2010-02-03 06:51:33 -0800 I finally managed to run the tests on patched Open C (got several non-working version of it). My testsuite that I built explicitly to be the reference for this patch didn't start after the patched Open C which isn't such nice thing as now I don't have real baseline to go with. tofte + xbarb 2933ms + 10567ms = 13500ms which is half the original time, but still lacks from my patch. To fix the patch will make the time taken to skyrocket in that or something more drastic changes is required for Symbian. Using Qt is no option here as QDateTime doesn't offer API to get DST. Maybe if QDateTime API would be changed. And the same bug is there too.. 214514 26 koshuin 2010-04-20 00:40:54 -0700 Open C fixes have been tested and speed is at acceptable level. I'll close the issue for now and check back on once we have new Open C version released. 221145 27 s.mathur 2010-05-05 09:32:06 -0700 (In reply to comment #26) > Open C fixes have been tested and speed is at acceptable level. I'll close the > issue for now and check back on once we have new Open C version released. For record keeping only: Internal OpenC bug for this fix is TSW VPOL-7WS7P2. (Janne, please correct if necessary) 41679 2009-10-22 13:08:52 -0700 2009-12-03 06:41:20 -0800 proposed patch 30681.patch text/plain 2883 s.mathur SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZw0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIEphdmFTY3Jp cHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gNDk5NTApCisrKyBKYXZhU2NyaXB0Q29yZS9DaGFu Z2VMb2cJKHdvcmtpbmcgY29weSkKQEAgLTEsMyArMSwxNCBAQAorMjAwOS0xMC0yMiAgU2lkZGhh cnRoIE1hdGh1ciAgPHNpZGRoYXJ0aC5tYXRodXJAbm9raWEuY29tPgorCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFN5bWJpYW4gcG9ydDogSlMgRGF0ZSBv cGVyYXRpb25zIHZlcnkgc2xvdyBkdWUgdG8gZmxha3kgUE9TSVggZGF0ZS90aW1lIGltcGxlbWVu dGF0aW9uCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0z MDY4MQorCisgICAgICAgICogd3RmL0RhdGVNYXRoLmNwcDoKKyAgICAgICAgKFdURjo6Z2V0VVRD T2Zmc2V0KToKKyAgICAgICAgKFdURjo6Z2V0RFNUT2Zmc2V0KToKKwogMjAwOS0xMC0yMSAgSm9u IEhvbmV5Y3V0dCAgPGpob25leWN1dHRAYXBwbGUuY29tPgogCiAgICAgICAgIDxyZGFyOi8vcHJv YmxlbS83MjcwMzIwPiBTY3JlZW5zaG90cyBvZiBvZmYtc2NyZWVuIHBsdWctaW5zIGFyZSBibGFu awpJbmRleDogSmF2YVNjcmlwdENvcmUvd3RmL0RhdGVNYXRoLmNwcA0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0t IEphdmFTY3JpcHRDb3JlL3d0Zi9EYXRlTWF0aC5jcHAJKHJldmlzaW9uIDQ5OTQxKQorKysgSmF2 YVNjcmlwdENvcmUvd3RmL0RhdGVNYXRoLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNzAsNiArNzAs MTAgQEAgZXh0ZXJuICJDIiBzaXplX3Qgc3RyZnRpbWUoY2hhciAqIGNvbnN0IAogZXh0ZXJuICJD IiBzdHJ1Y3QgdG0gKiBsb2NhbHRpbWUoY29uc3QgdGltZV90ICp0aW1lcik7CiAjZW5kaWYKIAor I2lmIFBMQVRGT1JNKFNZTUJJQU4pCisjaW5jbHVkZSA8ZTMyc3RkLmg+CisjZW5kaWYKKwogI2lm IEhBVkUoU1lTX1RJTUVfSCkKICNpbmNsdWRlIDxzeXMvdGltZS5oPgogI2VuZGlmCkBAIC00MTEs NiArNDE1LDcgQEAgc3RhdGljIGludCBzX25vdGlmaWNhdGlvblRva2VuOwogICovCiBkb3VibGUg Z2V0VVRDT2Zmc2V0KCkKIHsKKyAgICBpbnQzMl90IHV0Y09mZnNldCA9IDA7IAogI2lmIFBMQVRG T1JNKERBUldJTikKICAgICBpZiAoc19oYXZlQ2FjaGVkVVRDT2Zmc2V0KSB7CiAgICAgICAgIGlu dCBub3RpZmllZDsKQEAgLTQxOCwxNCArNDIzLDE3IEBAIGRvdWJsZSBnZXRVVENPZmZzZXQoKQog ICAgICAgICBpZiAoc3RhdHVzID09IE5PVElGWV9TVEFUVVNfT0sgJiYgIW5vdGlmaWVkKQogICAg ICAgICAgICAgcmV0dXJuIHNfY2FjaGVkVVRDT2Zmc2V0OwogICAgIH0KLSNlbmRpZgogCi0gICAg aW50MzJfdCB1dGNPZmZzZXQgPSBjYWxjdWxhdGVVVENPZmZzZXQoKTsKKyAgICB1dGNPZmZzZXQg PSBjYWxjdWxhdGVVVENPZmZzZXQoKTsKIAotI2lmIFBMQVRGT1JNKERBUldJTikKICAgICAvLyBU aGVvcmV0aWNhbGx5LCBpdCBpcyBwb3NzaWJsZSB0aGF0IHNldmVyYWwgdGhyZWFkcyB3aWxsIGJl IGV4ZWN1dGluZyB0aGlzIGNvZGUgYXQgb25jZSwgaW4gd2hpY2ggY2FzZSB3ZSB3aWxsIGhhdmUg YSByYWNlIGNvbmRpdGlvbiwKICAgICAvLyBhbmQgYSBuZXdlciB2YWx1ZSBtYXkgYmUgb3Zlcndy aXR0ZW4uIEluIHByYWN0aWNlLCB0aW1lIHpvbmVzIGRvbid0IGNoYW5nZSB0aGF0IG9mdGVuLgog ICAgIHNfY2FjaGVkVVRDT2Zmc2V0ID0gdXRjT2Zmc2V0OworI2VsaWYgUExBVEZPUk0oU1lNQklB TikKKyAgICAvLyBvZmZzZXQgZnJvbSBVVEMgKmluY2x1ZGluZyogZGF5bGlnaHQgY29ycmVjdGlv biwgaWYgYW55IAorICAgIHV0Y09mZnNldCA9IFVzZXI6OlVUQ09mZnNldCgpLkludCgpKjEwMDA7 CisjZWxzZSAKKyAgICB1dGNPZmZzZXQgPSBjYWxjdWxhdGVVVENPZmZzZXQoKTsKICNlbmRpZgog CiAgICAgcmV0dXJuIHV0Y09mZnNldDsKQEAgLTQ2Nyw2ICs0NzUsNyBAQCBzdGF0aWMgZG91Ymxl IGdldERTVE9mZnNldFNpbXBsZShkb3VibGUgCiAvLyBHZXQgdGhlIERTVCBvZmZzZXQsIGdpdmVu IGEgdGltZSBpbiBVVEMKIHN0YXRpYyBkb3VibGUgZ2V0RFNUT2Zmc2V0KGRvdWJsZSBtcywgZG91 YmxlIHV0Y09mZnNldCkKIHsKKyNpZiAhUExBVEZPUk0oU1lNQklBTikgCiAgICAgLy8gT24gTWFj IE9TIFgsIHRoZSBjYWxsIHRvIGxvY2FsdGltZSAoc2VlIGdldERTVE9mZnNldFNpbXBsZSkgd2ls bCByZXR1cm4gaGlzdG9yaWNhbGx5IGFjY3VyYXRlCiAgICAgLy8gRFNUIGluZm9ybWF0aW9uIChl LmcuIE5ldyBaZWFsYW5kIGRpZCBub3QgaGF2ZSBEU1QgZnJvbSAxOTQ2IHRvIDE5NzQpIGhvd2V2 ZXIgdGhlIEphdmFTY3JpcHQKICAgICAvLyBzdGFuZGFyZCBleHBsaWNpdGx5IGRpY3RhdGVzIHRo YXQgaGlzdG9yaWNhbCBpbmZvcm1hdGlvbiBzaG91bGQgbm90IGJlIGNvbnNpZGVyZWQgd2hlbgpA QCAtNDg0LDYgKzQ5MywxMCBAQCBzdGF0aWMgZG91YmxlIGdldERTVE9mZnNldChkb3VibGUgbXMs IGRvCiAgICAgfQogCiAgICAgcmV0dXJuIGdldERTVE9mZnNldFNpbXBsZShtcyAvIG1zUGVyU2Vj b25kLCB1dGNPZmZzZXQpOworI2Vsc2UKKyAgICAvLyBnZXRVVENPZmZzZXQoKSBhbHJlYWR5IGhh cyBkYXlsaWdodCBzYXZpbmdzIAorICAgIHJldHVybiAwLjA7IAorI2VuZGlmCiB9CiAKIGRvdWJs ZSBncmVnb3JpYW5EYXRlVGltZVRvTVMoY29uc3QgR3JlZ29yaWFuRGF0ZVRpbWUmIHQsIGRvdWJs ZSBtaWxsaVNlY29uZHMsIGJvb2wgaW5wdXRJc1VUQykK 44235 2009-12-03 05:53:27 -0800 2009-12-28 23:37:18 -0800 another fix jsdate.diff text/plain 2880 koshuin ZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZyBiL0phdmFTY3JpcHRDb3JlL0No YW5nZUxvZwppbmRleCBhNTBjZjIyLi45ZjFjNjZiIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29y ZS9DaGFuZ2VMb2cKKysrIGIvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTgg QEAKKzIwMDktMTItMDMgIEphbm5lIEtvc2tpbmVuICA8amFubmUucC5rb3NraW5lbkBkaWdpYS5j b20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgVXNl IFN5bWJpYW4ncyB0aW1lIGZ1bmN0aW9ucyBpbiBEYXRlTWF0aAorICAgICAgICBodHRwczovL2J1 Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzA2ODEKKworICAgICAgICBPcGVuIEMncyBQ b3NpeC90aW1lIGZ1bmN0aW9ucyBhcmUgcmVhbGx5IHNsb3cgdG8gZXhlY3V0ZSB0aHVzCisgICAg ICAgIFN5bWJpYW4gc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gaXMgbmVlZGVkLgorCisgICAgICAg ICogSmF2YVNjcmlwdENvcmUucHJpOgorICAgICAgICAqIHd0Zi9EYXRlTWF0aC5jcHA6CisgICAg ICAgIChXVEY6OmNhbGN1bGF0ZVVUQ09mZnNldCk6CisgICAgICAgIChXVEY6OmNhbGN1bGF0ZURT VE9mZnNldCk6CisKIDIwMDktMTItMDIgIE9saXZlciBIdW50ICA8b2xpdmVyQGFwcGxlLmNvbT4K IAogICAgICAgICBSZXZpZXdlZCBieSBHYXZpbiBCYXJyYWNsb3VnaC4KZGlmZiAtLWdpdCBhL0ph dmFTY3JpcHRDb3JlL0phdmFTY3JpcHRDb3JlLnByaSBiL0phdmFTY3JpcHRDb3JlL0phdmFTY3Jp cHRDb3JlLnByaQppbmRleCBmMmZhOTgxLi40NjM4MmFhIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0 Q29yZS9KYXZhU2NyaXB0Q29yZS5wcmkKKysrIGIvSmF2YVNjcmlwdENvcmUvSmF2YVNjcmlwdENv cmUucHJpCkBAIC0xMiw2ICsxMiw3IEBAIENPTkZJRyhkZWJ1ZywgZGVidWd8cmVsZWFzZSkgewog c3ltYmlhbjogewogICAgICMgTmVlZCB0byBndWFyYW50ZWUgdGhpcyBjb21lcyBiZWZvcmUgc3lz dGVtIGluY2x1ZGVzIG9mIC9lcG9jMzIvaW5jbHVkZQogICAgIE1NUF9SVUxFUyArPSAiVVNFUklO Q0xVREUgLi4vSmF2YVNjcmlwdENvcmUvcHJvZmlsZXIiCisgICAgTElCUyArPSAtbHR6Y2xpZW50 CiB9CiAKIElOQ0xVREVQQVRIID0gXApkaWZmIC0tZ2l0IGEvSmF2YVNjcmlwdENvcmUvd3RmL0Rh dGVNYXRoLmNwcCBiL0phdmFTY3JpcHRDb3JlL3d0Zi9EYXRlTWF0aC5jcHAKaW5kZXggMTY5N2Rm NS4uMDg1ZmNhZCAxMDA2NDQKLS0tIGEvSmF2YVNjcmlwdENvcmUvd3RmL0RhdGVNYXRoLmNwcAor KysgYi9KYXZhU2NyaXB0Q29yZS93dGYvRGF0ZU1hdGguY3BwCkBAIC0xMDUsNiArMTA1LDExIEBA IGV4dGVybiAiQyIgc3RydWN0IHRtICogbG9jYWx0aW1lKGNvbnN0IHRpbWVfdCAqdGltZXIpOwog I2luY2x1ZGUgIkNhbGxGcmFtZS5oIgogI2VuZGlmCiAKKyNpZiBQTEFURk9STShTWU1CSUFOKQor I2luY2x1ZGUgPGUzMnN0ZC5oPgorI2luY2x1ZGUgPHR6Lmg+CisjZW5kaWYKKwogI2RlZmluZSBO YU4gc3RkOjpudW1lcmljX2xpbWl0czxkb3VibGU+OjpxdWlldF9OYU4oKQogCiB1c2luZyBuYW1l c3BhY2UgV1RGOwpAQCAtMzc0LDYgKzM3OSw3IEBAIGludCBlcXVpdmFsZW50WWVhckZvckRTVChp bnQgeWVhcikKIAogc3RhdGljIGludDMyX3QgY2FsY3VsYXRlVVRDT2Zmc2V0KCkKIHsKKyNpZiAh UExBVEZPUk0oU1lNQklBTikKICAgICB0aW1lX3QgbG9jYWxUaW1lID0gdGltZSgwKTsKICAgICB0 bSBsb2NhbHQ7CiAgICAgZ2V0TG9jYWxUaW1lKCZsb2NhbFRpbWUsICZsb2NhbHQpOwpAQCAtNDA0 LDYgKzQxMCwyMCBAQCBzdGF0aWMgaW50MzJfdCBjYWxjdWxhdGVVVENPZmZzZXQoKQogI2VuZGlm CiAKICAgICByZXR1cm4gc3RhdGljX2Nhc3Q8aW50MzJfdD4odXRjT2Zmc2V0ICogMTAwMCk7CisK KyNlbHNlIC8vIVBMQVRGT1JNKFNZTUJJQU4pCisgICAgaW50MzJfdCB1dGNPZmZzZXQgPSBVc2Vy OjpVVENPZmZzZXQoKS5JbnQoKSAqIDEwMDA7CisgICAgUlR6IHR6OworCisgICAgaWYgKHR6LkNv bm5lY3QoKSA9PSBLRXJyTm9uZSkgeworICAgICAgICBUUkFQX0lHTk9SRSgKKyAgICAgICAgICAg IHV0Y09mZnNldCAtPSAodHouSXNEYXlsaWdodFNhdmluZ09uTCgqdHouR2V0VGltZVpvbmVJZEwo KSkpID8gbXNQZXJIb3VyIDogMDsKKyAgICAgICAgICAgICkKKyAgICAgICAgdHouQ2xvc2UoKTsK KyAgICB9CisgICAgcmV0dXJuIHV0Y09mZnNldDsKKyNlbmRpZgorCiB9CiAKIC8qCkBAIC00NTYs NyArNDc2LDIzIEBAIHN0YXRpYyBkb3VibGUgY2FsY3VsYXRlRFNUT2Zmc2V0KGRvdWJsZSBtcywg ZG91YmxlIHV0Y09mZnNldCkKICAgICAgICAgbXMgPSAoZGF5ICogbXNQZXJEYXkpICsgbXNUb01p bGxpc2Vjb25kcyhtcyk7CiAgICAgfQogCisjaWYgIVBMQVRGT1JNKFNZTUJJQU4pCiAgICAgcmV0 dXJuIGNhbGN1bGF0ZURTVE9mZnNldFNpbXBsZShtcyAvIG1zUGVyU2Vjb25kLCB1dGNPZmZzZXQp OworI2Vsc2UKKyAgICBSVHogdHo7CisgICAgZG91YmxlIGRzdCA9IDAuMDsKKworICAgIGlmICh0 ei5Db25uZWN0KCkgPT0gS0Vyck5vbmUpIHsKKyAgICAgICAgVFRpbWUgdChJNjRET1VCTEVDQVNU KG1zKSAqIDEwMDApOworICAgICAgICB0ICs9IFRUaW1lSW50ZXJ2YWxZZWFycygxOTcwKTsKKyAg ICAgICAgVFJBUF9JR05PUkUoCisgICAgICAgICAgICBkc3QgPSAodHouSXNEYXlsaWdodFNhdmlu Z09uTCgqdHouR2V0VGltZVpvbmVJZEwoKSwgdCkpID8gbXNQZXJIb3VyIDogMDsKKyAgICAgICAg KQorICAgICAgICB0ei5DbG9zZSgpOworICAgIH0KKyAgICByZXR1cm4gIGRzdDsKKyNlbmRpZgor CiB9CiAKIHZvaWQgaW5pdGlhbGl6ZURhdGVzKCkK