Re: How does one debug uninitialized value usage from JavaScript (TB) ?
On (2013年01月30日 04:30), Gary Kwong wrote: --enable-valgrind --smc-check=all-non-file I was not clear enough. I was compling with --enable-valgrind, and uses --smc-check=all-non-file when TB was executed under valgrind/memcheck already. The only missing piece was --track-origins=yes, which I intentionally omitted due to memory capacity issues. I am investigating the situation under 64 bit linux carefully now to see I can run TB under memcheck comfortably with --track-origins=yes. TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Given the above, I'd like to propose the following long-term solutions: 1. Disable PGO/LTCG now. 2. Try to delay disabling PGO/LTCG as much as possible. 3. Try to delay disabling PGO/LTCG until the next time that we hit the limit, and disable PGO/LTCG then once and for all. In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? One big advantage of that is that we'd immediately stop suffering through PGO-only bugs. (I'm not necessarily advocating this, BTW, just observing that the two options are basically equivalent.) Also, stupid question time: is it possible to build on Windows with GCC and/or clang? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does one debug uninitialized value usage from JavaScript (TB) ?
On (2013年01月29日 19:02), Neil wrote: ISHIKAWA, Chiaki wrote: I see some code most notably LDAP code in comm-central is not 64bit clean Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time now... Now I cannot seem to find the problematic code quickly enough in the latest comm-central code. I should have raised a flag when I was compiling 64 bit version myself and noticed the problem. I recall seeing that a hash table was accessed using a key that is calculated using only lower 32 bits of address of an inserted object. I distinctively recall that an equality check was performed by the equality of the key, i.e., 32-bit address value(!) if I was not mistaken then. To the code's credit, there was a runtime check to abort the operation if the address is not 4 bytes or something. (Yes, it was runtime check as opposed to static check.) That is why I gave up on 64 bit compilation. Yes, the collision happening with this key calculation may be remote, but I can think of a memory allocator trying to classify address space using the upper 32 bits as a category and thus the multiple use of similar 32 bit lower addresses in such an allocator can be likely. Maybe that particular piece of code is not used in default compilation setting(?) If I can locate the piece of code, I will post it again. I believe GCC warned of size mismatch or something at compile time on this piece of code and this is how I noticed the problem. (Right now, my 64 bit compilation log is cluttered up due to the inclusion of valgrind annotation of a sort [producing unused static function warning in many files.] and I may have overlooked it.) If the code in question has not changed in the last couple of months, I should be able to locate it again. TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 01/31/2013 10:37 AM, Nicholas Nethercote wrote: On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Given the above, I'd like to propose the following long-term solutions: 1. Disable PGO/LTCG now. 2. Try to delay disabling PGO/LTCG as much as possible. 3. Try to delay disabling PGO/LTCG until the next time that we hit the limit, and disable PGO/LTCG then once and for all. In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. It would be quite huge pr loss if we suddenly were 10-20% slower in benchmarks. But we're getting better (that last spike is because bz managed to effectively optimize out one test). http://graphs.mozilla.org/graph.html#tests=[[73,1,1]]sel=nonedisplayrange=365datatype=running Has anyone run other than dromaeo? Peacekeeper perhaps? -Olli One big advantage of that is that we'd immediately stop suffering through PGO-only bugs. (I'm not necessarily advocating this, BTW, just observing that the two options are basically equivalent.) Also, stupid question time: is it possible to build on Windows with GCC and/or clang? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
smaug wrote: On 01/31/2013 10:37 AM, Nicholas Nethercote wrote: If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. Do we know (e.g. via profiling) where these optimisations need to be? (I don't know how feasible it would be but another approach would be to PGO less and less code until it starts affecting the microbenchmarks.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does one debug uninitialized value usage from JavaScript (TB) ?
ishikawa wrote: Neil wrote: ISHIKAWA, Chiaki wrote: I see some code most notably LDAP code in comm-central is not 64bit clean Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time now... Now I cannot seem to find the problematic code quickly enough in the latest comm-central code. I should have raised a flag when I was compiling 64 bit version myself and noticed the problem. I recall seeing that a hash table was accessed using a key that is calculated using only lower 32 bits of address of an inserted object. I have skimmed the LDAP code for hashtables but I can only find one that uses a 32-bit key and it is inserting int values, not pointers. If you should happen to trip over the code again, please do not hesitate to file a bug, thanks! -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: printerenumeration (nsIPrinterEnumerator)
Thanks to both, this is a must have bit of functionality .. for gadget based interfaces! Zack Weinberg za...@panix.com wrote in message news:r62dnejc_k946ptmnz2dnuvz_skdn...@mozilla.org... On 2013-01-30 2:23 PM, Daniel Holbert wrote: However, be warned that there are patches in bug 629500 to get rid of nsIPrinterEnumerator entirely (though that bug seems to have stalled a bit, so I don't know how soon that will happen). It's blocked on Windows-specific fixes (bug 693230) -- it looks like there's a patch in there, but nobody bothered to ask for review and it's also not clear whether it actually works. If anyone has low-level Windows GUI programming experience and spare brain cycles I could really use help with that part. The intention is still to remove nsIPrinterEnumerator entirely. All the tier-1 platforms nowadays discourage use of the OS-level printer enumeration APIs, because they have to talk to the network and may block the calling thread for an indefinite period. You're supposed to just let the OS-supplied print dialog boxes figure it out for you. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout performance such as Dromaeo and guimark2 (and 40% in one case), but no significant regressions in the startup time, and gmail interactions. Thanks to a series of telemetry measurements performed by Vladan on a Nightly build we did last week which had PGO/LTCG disabled, there are no telemetry probes which show a significant regression on builds without PGO/LTCG. Vladan is going to try to get this data out of a Tp5 run tomorrow as well, but we don't have any evidence to believe that the results of that experiments will be any different. Are the test run stats we're using here published somewhere? We should be tracking all this testing some place (a wiki page maybe?) so people can do their own investigation. I've always wondered if the tests we run during the pgo phase are sufficient to get good coverage over the entire app. Is it possible that we don't see gains in other areas because our pgo tests don't hit those areas? (I think there was an effort under way to expose these tests so they could be modified in try runs for better experimentation.) Generally I would make disabling pgo the last option after exhausting all other options. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 1/31/2013 6:39 AM, jmath...@mozilla.com wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout performance such as Dromaeo and guimark2 (and 40% in one case), but no significant regressions in the startup time, and gmail interactions. Thanks to a series of telemetry measurements performed by Vladan on a Nightly build we did last week which had PGO/LTCG disabled, there are no telemetry probes which show a significant regression on builds without PGO/LTCG. Vladan is going to try to get this data out of a Tp5 run tomorrow as well, but we don't have any evidence to believe that the results of that experiments will be any different. Are the test run stats we're using here published somewhere? We should be tracking all this testing some place (a wiki page maybe?) so people can do their own investigation. I've always wondered if the tests we run during the pgo phase are sufficient to get good coverage over the entire app. Is it possible that we don't see gains in other areas because our pgo tests don't hit those areas? (I think there was an effort under way to expose these tests so they could be modified in try runs for better experimentation.) Generally I would make disabling pgo the last option after exhausting all other options. As a historical note, when we first enabled PGO support for Windows our profiling scenario was start Firefox, wait 10 seconds, shut down Firefox. Enabling PGO with this profiling run provided us with 20-25% perf improvements in many of our benchmarks on Talos. We later changed it to the current set of profiling data[1] (Blueprint CSS samples, the SunSpider benchmark), and there was almost no visible change in the Talos numbers. I'm sure for very specific benchmarks we could improve perf by adding those things to the profiling run, but it's a very delicate art. The optimizer has to balance code size against speed, and it's not always obvious which way makes things better. (For example, we historically built with -Os + a few extra optimize flags on Linux instead of -O2 because producing smaller code generally made us faster than optimizing everything for speed.) -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=472706 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
How separate the analysis phase from the optimization based on the collected data? How are the results of the PGO runs stored? Can the optimization part be run independently? If yes would it be possible to collect the data through other means, let's say by doing a x86-64 build or only statically building modules? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 1/31/2013 2:37 AM, Nicholas Nethercote wrote: Also, stupid question time: is it possible to build on Windows with GCC and/or clang? It's definitely possible to build with Mingw GCC, but that is a major ABI-breaking change, and I think we lose the ability to compile against any Microsoft IDL interfaces. Clang has producing a MSVC-compatible ABI as a long-term goal, but it is not there yet, and I think it may still have problems parsing windows.h. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 1/31/2013 8:22 AM, papal...@gmail.com wrote: How separate the analysis phase from the optimization based on the collected data? How are the results of the PGO runs stored? Can the optimization part be run independently? If yes would it be possible to collect the data through other means, let's say by doing a x86-64 build or only statically building modules? Any crazy toolchain hacks like this are virtually unworkable. The internals of the PGO optimizer and data it uses are a black box. Without a doubt it would be less hassle to simply disable PGO than to try to hack around a deficient closed-source toolchain in this much detail. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2013-01-31 3:37 AM, Nicholas Nethercote wrote: On Thu, Jan 31, 2013 at 3:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Given the above, I'd like to propose the following long-term solutions: 1. Disable PGO/LTCG now. 2. Try to delay disabling PGO/LTCG as much as possible. 3. Try to delay disabling PGO/LTCG until the next time that we hit the limit, and disable PGO/LTCG then once and for all. In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? One big advantage of that is that we'd immediately stop suffering through PGO-only bugs. (I'm not necessarily advocating this, BTW, just observing that the two options are basically equivalent.) The PGO miscompilation bugs is a good point, thanks for bringing it up. Also, stupid question time: is it possible to build on Windows with GCC and/or clang? I don't have a lot of experience with mingw32, but to the best of my knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit support plus a number of C++ runtime library features, and a number of MSVC features, such as SEH. Clang on Windows is further away, with incomplete support for the Microsoft C++ ABI, inline assembly, and some compiler intrinsics. We may be able to consider this when the situation improves. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. It would be quite huge pr loss if we suddenly were 10-20% slower in benchmarks. But we're getting better (that last spike is because bz managed to effectively optimize out one test). http://graphs.mozilla.org/graph.html#tests=[[73,1,1]]sel=nonedisplayrange=365datatype=running Do we think the planned optimizations cause the gains through PGO to be less pronounced? If not, then slowdown in benchmarks and associated PR loss would be the same whenever we finally pulled the plug on PGO, right? (And thanks to smaug for pointing out my earlier direct-only reply just now.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2013-01-31 5:38 AM, Neil wrote: smaug wrote: On 01/31/2013 10:37 AM, Nicholas Nethercote wrote: If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. Do we know (e.g. via profiling) where these optimisations need to be? No. But imitating the optimizations performed by the PGO compiler will not be trivial. (I don't know how feasible it would be but another approach would be to PGO less and less code until it starts affecting the microbenchmarks.) That is kind of what we've been doing so far, and it has proven not to scale well. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2013-01-31 6:39 AM, jmath...@mozilla.com wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout performance such as Dromaeo and guimark2 (and 40% in one case), but no significant regressions in the startup time, and gmail interactions. Thanks to a series of telemetry measurements performed by Vladan on a Nightly build we did last week which had PGO/LTCG disabled, there are no telemetry probes which show a significant regression on builds without PGO/LTCG. Vladan is going to try to get this data out of a Tp5 run tomorrow as well, but we don't have any evidence to believe that the results of that experiments will be any different. Are the test run stats we're using here published somewhere? We should be tracking all this testing some place (a wiki page maybe?) so people can do their own investigation. See the dependencies of bug 833881 for the details of the measurements. I've always wondered if the tests we run during the pgo phase are sufficient to get good coverage over the entire app. Is it possible that we don't see gains in other areas because our pgo tests don't hit those areas? (I think there was an effort under way to expose these tests so they could be modified in try runs for better experimentation.) Yes, it's definitely possible to get more PGO coverage, but as far as I can see, the last time we changed the pageset we load during PGO was in 2009 (bug 472706). Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
- Original Message - We should also remind that there would be an infra load win from disabling Windows PGO builds. Plus less of a lead time waiting for PGO results before an inbound - mozilla-central merge can be performed :-D (even if we keep PGO on other platforms, Windows was always the long pole) Ed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2013-01-31 10:33 AM, Till Schneidereit wrote: In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. It would be quite huge pr loss if we suddenly were 10-20% slower in benchmarks. But we're getting better (that last spike is because bz managed to effectively optimize out one test). http://graphs.mozilla.org/graph.html#tests=[[73,1,1]]sel=nonedisplayrange=365datatype=running Do we think the planned optimizations cause the gains through PGO to be less pronounced? If not, then slowdown in benchmarks and associated PR loss would be the same whenever we finally pulled the plug on PGO, right? I'm not sure what you mean. If we get 10% slower in Dromaeo by disabling PGO and take a patch which makes us 20% faster regardless of PGO, then we should expect an approximate 10% win as a result. But generally, the game of trying to beat the compiler in its optimizations is futile, since they can outsmart most programmers on their worst day. :-) Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does one debug uninitialized value usage from JavaScript (TB) ?
(2013/01/31 19:46), Neil wrote: ishikawa wrote: Neil wrote: ISHIKAWA, Chiaki wrote: I see some code most notably LDAP code in comm-central is not 64bit clean Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time now... Now I cannot seem to find the problematic code quickly enough in the latest comm-central code. I should have raised a flag when I was compiling 64 bit version myself and noticed the problem. I recall seeing that a hash table was accessed using a key that is calculated using only lower 32 bits of address of an inserted object. I have skimmed the LDAP code for hashtables but I can only find one that uses a 32-bit key and it is inserting int values, not pointers. If you should happen to trip over the code again, please do not hesitate to file a bug, thanks! Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-central code for development/debugging TB. https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53 The code uses a lower 32 bit of address obviously. And if I recall correctly, when I compiled TB under 64 bit and chased the warning: cast from pointer to integer of different size (or vice versa?) I found a place where the equality of the key valuex was considered the equality of two hash entries (under 32 bit, I suppose this is correct.). To its credit, the code clearly checks that the address space is 32 bits at run-time. If this piece of code is not used in the production version of TB, fine. (Also, ldap may not be that widely used outside enterprise setting, so I suspect hitting this bug may not be a high-probability event.) Actually, when I tried to look at the different sizes of pointer and integer issues, and found this code, I gave up on compiling 64 bits. Funny, I have no idea why I thought it was ldap. (could it be that it uses this mozilla library [the libraries created below ./mozilla subdirectory] somehow?) I disabled ldap in MOZCONFIG and thought I would be OK... Anyway, I will raise a flag when I notice the code where equality of hash values is considered the equality of the hash entries. I thought it was strange when I read the 64 bit version of TB was released, and I assumed that the offending code (which somehow I tought was ldap??) is not enabled. But maybe the flaw in TB code was not noticed before ? TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thu, Jan 31, 2013 at 4:42 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2013-01-31 10:33 AM, Till Schneidereit wrote: In the long run, 1 and 3 are the same. If we know we're going to turn it off, why not bite the bullet and do it now? Because we're still missing plenty of optimizations in our code to be fast in microbenchmarks. It would be quite huge pr loss if we suddenly were 10-20% slower in benchmarks. But we're getting better (that last spike is because bz managed to effectively optimize out one test). http://graphs.mozilla.org/graph.html#tests=[[73,1,1]]sel=nonedisplayrange=365datatype=running Do we think the planned optimizations cause the gains through PGO to be less pronounced? If not, then slowdown in benchmarks and associated PR loss would be the same whenever we finally pulled the plug on PGO, right? I'm not sure what you mean. If we get 10% slower in Dromaeo by disabling PGO and take a patch which makes us 20% faster regardless of PGO, then we should expect an approximate 10% win as a result. But generally, the game of trying to beat the compiler in its optimizations is futile, since they can outsmart most programmers on their worst day. :-) Sure. What I was asking is precisely if the optimizations we're betting on will have the property of not being affected by PGO. If we take a patch now that makes us 10% faster with PGO enabled and then later lose 10% by switching off PGO, then the PR effect will be the same as switching off PGO right now. If, OTOH, we switch off PGO while at the same time pushing patches that get us back all of the performance we lost through it, we shouldn't have any PR fallout at all. Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Minimizing Layers churn for refactoring
Hi all, Over the last couple of years there were a lot of new additions and changes to the layers sytems which have caused the current implementation to become hard to maintain with a lot of code duplication. The graphics team has been working hard on re-designing part of the layers system, this also means refactoring a significant portion of the existing code. Since this means a lot of work this is being executed on the Graphics project branch. As we are getting closer to completing the work (although completion is still some ways off), it's becoming increasingly difficult to merge work being done on mozilla-central. In light of the end-goal of having a layers system that's easier to amend and maintain as soon as possible we'd therefore like to ask everyone working on the platform to minimize work done on layers, and to make sure all patches going into this part of the code to receive explicit review from somebody on the graphics team. If you have any questions or want to learn more about the refactoring feel free to contact myself or another member of the graphics team. You can find the refactoring work on https://hg.mozilla.org/projects/graphics. Best regards, Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does one debug uninitialized value usage from JavaScript (TB) ?
(2013/02/01 0:41), ISHIKAWA, Chiaki wrote: (2013/01/31 19:46), Neil wrote: ishikawa wrote: Neil wrote: ISHIKAWA, Chiaki wrote: I see some code most notably LDAP code in comm-central is not 64bit clean Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time now... Now I cannot seem to find the problematic code quickly enough in the latest comm-central code. I should have raised a flag when I was compiling 64 bit version myself and noticed the problem. I recall seeing that a hash table was accessed using a key that is calculated using only lower 32 bits of address of an inserted object. I have skimmed the LDAP code for hashtables but I can only find one that uses a 32-bit key and it is inserting int values, not pointers. If you should happen to trip over the code again, please do not hesitate to file a bug, thanks! Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-central code for development/debugging TB. https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53 The code uses a lower 32 bit of address obviously. And if I recall correctly, when I compiled TB under 64 bit and chased the warning: cast from pointer to integer of different size (or vice versa?) I found a place where the equality of the key valuex was considered the equality of two hash entries (under 32 bit, I suppose this is correct.). To its credit, the code clearly checks that the address space is 32 bits at run-time. If this piece of code is not used in the production version of TB, fine. (Also, ldap may not be that widely used outside enterprise setting, so I suspect hitting this bug may not be a high-probability event.) Actually, when I tried to look at the different sizes of pointer and integer issues, and found this code, I gave up on compiling 64 bits. Funny, I have no idea why I thought it was ldap. (could it be that it uses this mozilla library [the libraries created below ./mozilla subdirectory] somehow?) I disabled ldap in MOZCONFIG and thought I would be OK... Anyway, I will raise a flag when I notice the code where equality of hash values is considered the equality of the hash entries. I thought it was strange when I read the 64 bit version of TB was released, and I assumed that the offending code (which somehow I tought was ldap??) is not enabled. But maybe the flaw in TB code was not noticed before ? TIA I suppose that nobody has hit the run-time assertion in the said hash function suggests that it is dead code as far production TB is concerned. Also, I may have read the code incorrectly. In any case, the incorrect use on 64 bit system would result in runtime assertion failure (correct? Or is PR_ASSERT() just a slap on the hand instead of real abort()?), we will know if this routine is misued on 64 bit. So I suspect this is a low priority issue for now. TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thursday, January 31, 2013 8:14:01 AM UTC-6, Gregory Szorc wrote: My reading of Ehsan's summary is that there is no significant *user* benefit (read: perf win) of PGO. If there is no *user* benefit, then the only data that remains to justify PGO are the benchmark results. Therefore, I believe we should disable PGO unless there is a convincing argument for the benchmark results that sufficiently offsets the pain PGO inflicts. Is there? http://graphs.mozilla.org/graph.html#tests=[[83,94,12],[83,1,12]]sel=nonedisplayrange=365datatype=running Ts, Paint shows an improvement of 14%. This is with Firefox and Firefox-Non-PGO, which I believe to be mc. Also while I can't seem to find it on pertastic, Tresize appears to enjoy a 9% improvement with pgo on mc. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout performance such as Dromaeo and guimark2 (and 40% in one case), but no significant regressions in the startup time, and gmail interactions. Thanks to a series of telemetry measurements performed by Vladan on a Nightly build we did last week which had PGO/LTCG disabled, there are no telemetry probes which show a significant regression on builds without PGO/LTCG. Vladan is going to try to get this data out of a Tp5 run tomorrow as well, but we don't have any evidence to believe that the results of that experiments will be any different. Isn't PGO worth something like 15% on Ts? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does one debug uninitialized value usage from JavaScript (TB) ?
On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote: Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-central code for development/debugging TB. https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53 This is NSS code, which is a separate codebase included in mozilla-central and updated periodically. Judging from the context, this is someone using the low 32 bits as a hash key; since it's a hashtable, I'm going to assume that it's expected to have some amount of collisions, so the conversion of a possibly-64-bit pointer to a 32-bit value is safe here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2013-01-31 11:43 AM, Kyle Huey wrote: On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout performance such as Dromaeo and guimark2 (and 40% in one case), but no significant regressions in the startup time, and gmail interactions. Thanks to a series of telemetry measurements performed by Vladan on a Nightly build we did last week which had PGO/LTCG disabled, there are no telemetry probes which show a significant regression on builds without PGO/LTCG. Vladan is going to try to get this data out of a Tp5 run tomorrow as well, but we don't have any evidence to believe that the results of that experiments will be any different. Isn't PGO worth something like 15% on Ts? That was what I thought, but local measurements performed by dmandelin proved otherwise. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2013-01-31 10:59 AM, jmath...@mozilla.com wrote: As a historical note, when we first enabled PGO support for Windows our profiling scenario was start Firefox, wait 10 seconds, shut down Firefox. Enabling PGO with this profiling run provided us with 20-25% perf improvements in many of our benchmarks on Talos. We later changed it to the current set of profiling data[1] (Blueprint CSS samples, the SunSpider benchmark), and there was almost no visible change in the Talos numbers. This seems to indicate our current coverage isn't oriented toward performance gains users will see, and that there are potential gains to be found. All the more reason to keep pgo around a while longer and figure out how we can simplify testing with different test runs. There are costs to keeping PGO enabled, and while we can argue that we _could_ be getting more PGO gain by providing a better profile, one could counter-argue that engineers can spend more time optimizing other things if they didn't need to find the perfect profile (which is sort of a black magic.) We should also remind that there would be an infra load win from disabling Windows PGO builds. IMHO, if it's a choice between infra load and better performance in the end product, performance should win out. I agree, infrastructure load is not relevant to this conversation. There are tons of other ways to improve that besides disabling PGO. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-01-31 11:43 AM, Kyle Huey wrote: Isn't PGO worth something like 15% on Ts? That was what I thought, but local measurements performed by dmandelin proved otherwise. Uh, don't we have a bigger problem then? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2013-01-31 11:58 AM, Kyle Huey wrote: On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: On 2013-01-31 11:43 AM, Kyle Huey wrote: Isn't PGO worth something like 15% on Ts? That was what I thought, but local measurements performed by dmandelin proved otherwise. Uh, don't we have a bigger problem then? The problem being? Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 01/31/13 10:59 AM, jmath...@mozilla.com wrote: IMHO, if it's a choice between infra load and better performance in the end product, performance should win out. We're not talking about infrastructure load here, we're talking about whether or not we can compile at all. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thu, Jan 31, 2013 at 9:09 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-01-31 11:58 AM, Kyle Huey wrote: On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhgari@gmail.**com ehsan.akhg...@gmail.com wrote: On 2013-01-31 11:43 AM, Kyle Huey wrote: Isn't PGO worth something like 15% on Ts? That was what I thought, but local measurements performed by dmandelin proved otherwise. Uh, don't we have a bigger problem then? The problem being? That Ts is bogus? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 1/31/13 10:33 AM, Till Schneidereit wrote: Do we think the planned optimizations cause the gains through PGO to be less pronounced? It... depends. There are a few things at play here. First of all, our current profiling at least for DOM and layout stuff is largely looking for the wallet where the light is good, that is to say happening on Mac. Which happens to be the one desktop platform on which we don't do PGO. As a result, code micro-optimized based on those profiling results tends to inline a lot of things (in many cases forcing inlining via MOZ_ALWAYS_INLINE where the compiler wasn't otherwise doing it) and hope for the best. This works pretty well for microbenchmarks; how it works at scale is an interesting question that we don't have a great answer to yet because we don't have good things to measure. The flip side of that is that we've been a bit more resistant to the write the code and let PGO sort it out approach some have advocated, so turning off PGO won't be a total disaster for such code. Second, in any testcase that involves both jitcode and C++ code, turning off PGO will only affect the C++ code, of course. So to the extent that we speed up the C++ parts of the app relative to the jitcode, turning off PGO becomes less of a hit in testcases that involve both. Of course as we optimize the JIT the balance swings in the other direction. The real benefit of PGO is its ability to somewhat easily optimize the actual workload you care about instead of microbenchmarks For microbenchmarks proper we can always make them faster manually; the question is at what cost. If not, then slowdown in benchmarks and associated PR loss would be the same whenever we finally pulled the plug on PGO, right? Even if we posit the slowdown is the same, the PR loss is not. Say browser A takes time T to run a test, browser B takes time 1.2T and browser C takes time 0.8T. Say browsers B and C both suffer a 10% regression on that test. Now the times are: A: T, B: 1.32T, C: 0.88T From a PR point of view, the key part is that browser B is now 30% slower than A, but C is still 12% faster. So it's not clear to me that there would be any particularly bad PR for C at all. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 1/31/2013 10:51 AM, Ehsan Akhgari wrote: On 2013-01-31 11:43 AM, Kyle Huey wrote: On Wed, Jan 30, 2013 at 8:03 PM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: We then tried to get a sense of how much of a win the PGO optimizations are. Thanks to a series of measurements by dmandelin, we know that disabling PGO/LTCG will result in a regression of about 10-20% on benchmarks which examine DOM and layout performance such as Dromaeo and guimark2 (and 40% in one case), but no significant regressions in the startup time, and gmail interactions. Thanks to a series of telemetry measurements performed by Vladan on a Nightly build we did last week which had PGO/LTCG disabled, there are no telemetry probes which show a significant regression on builds without PGO/LTCG. Vladan is going to try to get this data out of a Tp5 run tomorrow as well, but we don't have any evidence to believe that the results of that experiments will be any different. Isn't PGO worth something like 15% on Ts? That was what I thought, but local measurements performed by dmandelin proved otherwise. For what it's worth, reading https://bugzilla.mozilla.org/show_bug.cgi?id=833890, I do not get the impression that dmandelin proved otherwise. His startup tests have very low statistical confidence (n=2, n=3), and someone who disclaims his own findings. It may be evidence that PGO is not a Ts win, but it is weak evidence at best. Our Talos results may be measuring imperfect things, but we have enough datapoints that we can draw statistical conclusions from them confidently. If you want to argue to me that they're wrong, you're going to have produce more compelling evidence. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: printerenumeration (nsIPrinterEnumerator)
What are gadget based interfaces, and why do they need to query the browser to enumerate printers? ~Daniel On 01/31/2013 02:54 AM, rvj wrote: Thanks to both, this is a must have bit of functionality .. for gadget based interfaces! Zack Weinberg za...@panix.com wrote in message news:r62dnejc_k946ptmnz2dnuvz_skdn...@mozilla.org... On 2013-01-30 2:23 PM, Daniel Holbert wrote: However, be warned that there are patches in bug 629500 to get rid of nsIPrinterEnumerator entirely (though that bug seems to have stalled a bit, so I don't know how soon that will happen). It's blocked on Windows-specific fixes (bug 693230) -- it looks like there's a patch in there, but nobody bothered to ask for review and it's also not clear whether it actually works. If anyone has low-level Windows GUI programming experience and spare brain cycles I could really use help with that part. The intention is still to remove nsIPrinterEnumerator entirely. All the tier-1 platforms nowadays discourage use of the OS-level printer enumeration APIs, because they have to talk to the network and may block the calling thread for an indefinite period. You're supposed to just let the OS-supplied print dialog boxes figure it out for you. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thu, Jan 31, 2013 at 01:07:39PM -0500, Ted Mielczarek wrote: After consideration, I think we ought to just bite the bullet and disable PGO. We have no other way to fix this issue. All other work we can do simply pushes it down the road. As our recent history has shown, we simply don't have the ability to fix this in any long-term sense. If Microsoft doesn't fix their toolchain, there's nothing we can do. I'd say that if we can keep our benchmark scores by selectively enabling PGO in some directories (instead of the current scheme of selectively disabling it), we should go for that. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY meaningful on Windows (they currently only do anything on gcc or clang builds)? If we did, might that get back some of the gain from turning off PGO? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thu, Jan 31, 2013 at 12:12 PM, Kyle Huey m...@kylehuey.com wrote: On Thu, Jan 31, 2013 at 9:09 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-01-31 11:58 AM, Kyle Huey wrote: On Thu, Jan 31, 2013 at 8:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhgari@gmail.**com ehsan.akhg...@gmail.com wrote: On 2013-01-31 11:43 AM, Kyle Huey wrote: Isn't PGO worth something like 15% on Ts? That was what I thought, but local measurements performed by dmandelin proved otherwise. Uh, don't we have a bigger problem then? The problem being? That Ts is bogus? Could be, but that is a completely different conversation which is off topic for this thread. -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
- Original Message - Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY meaningful on Windows (they currently only do anything on gcc or clang builds)? If we did, might that get back some of the gain from turning off PGO? Nope: http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/2dbdca4d-c0c0-40a3-993b-dc78817be26e/ A MSVC team member recommended using PGO instead. =/ -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron dba...@dbaron.org wrote: Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY meaningful on Windows (they currently only do anything on gcc or clang builds)? If we did, might that get back some of the gain from turning off PGO? On Thursday 2013-01-31 13:59 -0500, Ehsan Akhgari wrote: MSVC supports __assume, which is similar but not quite the same. I'm very skeptical that by simply using __assume we'll regain the benchmark hit resulting from turning PGO off. I certainly wouldn't expect to regain anything close to the whole benchmark hit, but I could imagine regaining 10% or 20% of it with something similar (which Mike's post notes __assume isn't). -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 1/31/13 11:21 AM, L. David Baron wrote: On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron dba...@dbaron.org wrote: Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY meaningful on Windows (they currently only do anything on gcc or clang builds)? If we did, might that get back some of the gain from turning off PGO? Patrick McManus benchmarked the benefit of gcc's likely/unlikely macros on the Linux kernel (where they are very commonly used). He found _no_ measurable differences after redefining likely/unlikely to nops. Patrick ran his tests in 2008, so perhaps the results would different with a recent version of gcc. I would also be interested is seeing test results when reversing the macros' definitions (#define likely - unlikely). :) http://bitsup.blogspot.com/2008/04/measuring-performance-of-linux-kernel.html chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On Jan 31, 12:04 pm, Chris Peterson cpeter...@mozilla.com wrote: On 1/31/13 11:21 AM, L. David Baron wrote: On Thu, Jan 31, 2013 at 1:31 PM, L. David Baron dba...@dbaron.org wrote: Is it possible we might be able to make MOZ_LIKELY and MOZ_UNLIKELY meaningful on Windows (they currently only do anything on gcc or clang builds)? If we did, might that get back some of the gain from turning off PGO? Patrick McManus benchmarked the benefit of gcc's likely/unlikely macros on the Linux kernel (where they are very commonly used). He found _no_ measurable differences after redefining likely/unlikely to nops. Patrick ran his tests in 2008, so perhaps the results would different with a recent version of gcc. I would also be interested is seeing test results when reversing the macros' definitions (#define likely - unlikely). :) http://bitsup.blogspot.com/2008/04/measuring-performance-of-linux-ker... Drive-by comment: likely/unlikely is of course highly architecture dependent. On PowerPC, for example, these may change the way the likely bit is set on the branch, which is used as part of branch prediction. On that and similar architectures, likely/unlikely can significantly improve the performance of branchy code. I've started writing this into TenFourFox in certain places. On cross-platform code like the Linux kernel, I would hazard to say it makes quite a difference across the spectrum. But even where this feature doesn't exist (post-Netburst x86, most ARM), it is my understanding that it will still cause code generation to favour the likely branch such as making it more likely to stay in the I-cache, etc. Cameron Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
Just to echo what David said, PGO builds cause amorphous stability and even graphics/layout bugs (for instance bug 831296) that we're forced to investigate in engineering and QA for a specific release, even though the issues aren't typically caused by actual in-product regressions. Additionally, inconsistent PGO builds have been known to cause one-off crash spikes (like bug 799118) which prove to be a waste of time for our engineering/stability/QA groups. It's definitely a world of pain that we should avoid if at all possible. I'm of the opinion that we should nuke it from orbit (option #1) if there's no obvious/significant user performance gains. -Alex On Jan 31, 2013, at 11:49 AM, David Anderson bailo...@gmail.com wrote: On Thursday, January 31, 2013 8:54:50 AM UTC-8, Ehsan Akhgari wrote: On 2013-01-31 10:59 AM, ... wrote: As a historical note, when we first enabled PGO support for Windows our profiling scenario was start Firefox, wait 10 seconds, shut down Firefox. Enabling PGO with this profiling run provided us with 20-25% perf improvements in many of our benchmarks on Talos. We later changed it to the current set of profiling data[1] (Blueprint CSS samples, the SunSpider benchmark), and there was almost no visible change in the Talos numbers. This seems to indicate our current coverage isn't oriented toward performance gains users will see, and that there are potential gains to be found. All the more reason to keep pgo around a while longer and figure out how we can simplify testing with different test runs. There are costs to keeping PGO enabled, and while we can argue that we _could_ be getting more PGO gain by providing a better profile, one could counter-argue that engineers can spend more time optimizing other things if they didn't need to find the perfect profile (which is sort of a black magic.) We should also remind that there would be an infra load win from disabling Windows PGO builds. IMHO, if it's a choice between infra load and better performance in the end product, performance should win out. I agree, infrastructure load is not relevant to this conversation. There are tons of other ways to improve that besides disabling PGO. Cheers, Ehsan I'm weighing in a little late here, but from the JS team's perspective, PGO is a nightmare. It introduces subtle compiler bugs (often topcrashes) that are extremely difficult to track down. We end up littering the codebase with de-PGO hints. To date I have yet to see a PGO-only crash that manifests in the JS engine, that was not directly caused by PGO. Related, I don't think MOZ_LIKELY/UNLIKELY are either a good idea or would cover the PGO gap. PGO does way more than just branch prediction, it has all sorts of speculative partial inlining and register allocation tricks. (That, unfortunately, are buggy.) Anyway, disabling PGO is music to my ears - I'd bet money that our overall crash-stats will improve. -David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2013-01-31 2:49 PM, David Anderson wrote: On Thursday, January 31, 2013 8:54:50 AM UTC-8, Ehsan Akhgari wrote: On 2013-01-31 10:59 AM, ... wrote: As a historical note, when we first enabled PGO support for Windows our profiling scenario was start Firefox, wait 10 seconds, shut down Firefox. Enabling PGO with this profiling run provided us with 20-25% perf improvements in many of our benchmarks on Talos. We later changed it to the current set of profiling data[1] (Blueprint CSS samples, the SunSpider benchmark), and there was almost no visible change in the Talos numbers. This seems to indicate our current coverage isn't oriented toward performance gains users will see, and that there are potential gains to be found. All the more reason to keep pgo around a while longer and figure out how we can simplify testing with different test runs. There are costs to keeping PGO enabled, and while we can argue that we _could_ be getting more PGO gain by providing a better profile, one could counter-argue that engineers can spend more time optimizing other things if they didn't need to find the perfect profile (which is sort of a black magic.) We should also remind that there would be an infra load win from disabling Windows PGO builds. IMHO, if it's a choice between infra load and better performance in the end product, performance should win out. I agree, infrastructure load is not relevant to this conversation. There are tons of other ways to improve that besides disabling PGO. Cheers, Ehsan I'm weighing in a little late here, but from the JS team's perspective, PGO is a nightmare. It introduces subtle compiler bugs (often topcrashes) that are extremely difficult to track down. We end up littering the codebase with de-PGO hints. To date I have yet to see a PGO-only crash that manifests in the JS engine, that was not directly caused by PGO. Related, I don't think MOZ_LIKELY/UNLIKELY are either a good idea or would cover the PGO gap. PGO does way more than just branch prediction, it has all sorts of speculative partial inlining and register allocation tricks. (That, unfortunately, are buggy.) Anyway, disabling PGO is music to my ears - I'd bet money that our overall crash-stats will improve. As I explained in my first email, this thread does not cover PGO in the JS engine. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
Here are some additional test suites from perftastic for reference. Tp5 from last summer, XP and Win7: http://graphs.mozilla.org/graph.html#tests=[[177,94,12],[177,1,12],[177,94,1],[177,1,1]]sel=nonedisplayrange=365datatype=running Sunspider 2, Win7: http://graphs.mozilla.org/graph.html#tests=[[162,1,12],[162,94,12]]sel=nonedisplayrange=365datatype=running Ts MED Dirty Profile, XP and Win7: http://graphs.mozilla.org/graph.html#tests=[[53,94,12],[53,1,12],[53,1,1],[53,94,1]]sel=nonedisplayrange=365datatype=running Ts, Paint, XP and Win7: http://graphs.mozilla.org/graph.html#tests=[[83,94,12],[83,1,12],[83,94,1],[83,1,1]]sel=nonedisplayrange=365datatype=running ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
Also, stupid question time: is it possible to build on Windows with GCC and/or clang? Yes, even better, it's possible to build on Linux for Windows using GCC, see: https://developer.mozilla.org/en-US/docs/Cross_Compile_Mozilla_for_Mingw32 It should be also possible to build on Windows, but AFAICS noone did it for a while, so it would probably require some fixes. Those builds are not yet feature complete, but it's just a matter of (usually not too hard) fixes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
I don't have a lot of experience with mingw32, but to the best of my knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit support Currently the best option for mingw is mingw-w64 for that (besides what the name suggests) supports both 32 and 64-bit targets. Also it works with any version of GCC newer than 4.4, AFAIR. plus a number of C++ runtime library features, mingw uses GCC's stdc++ and adds only a few limitations comparing to other stdc++ targets. and a number of MSVC features, such as SEH. Yes, SEH is a problem. FWIW, GCC 4.8 will have limited SEH support for 64-bit targets. Jacek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does one debug uninitialized value usage from JavaScript (TB) ?
(2013/02/01 1:48), Joshua Cranmer wrote: On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote: Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-central code for development/debugging TB. https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53 This is NSS code, which is a separate codebase included in mozilla-central and updated periodically. Judging from the context, this is someone using the low 32 bits as a hash key; since it's a hashtable, I'm going to assume that it's expected to have some amount of collisions, so the conversion of a possibly-64-bit pointer to a 32-bit value is safe here. Yes, I was also expecting to see the collision resolution. But, if my reading was correct, in one place, I thought the equality of the hash value was deemed instantly to be the equality of the object. (That is why I thought something was fishy, and I assume that the coder thought it would work only under in 32bit address space. Thus the check for 32bit address space.) I should have raised the flag then and there. But I went on other things, and later when I learned the availability of 64bit version of TB, I was surprised. It could be that my reading of equality check may have been incorrect. Anyway, I assume that the code would bomb out by PR_ASSERT() if incorrect usage of this funciton in 64 bit address space is encountered at run time, and assuming that it has not happened to anybody (?), then probably this part of the code base is not used in production TB. TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does one debug uninitialized value usage from JavaScript (TB) ?
(2013/02/01 11:34), Joshua Cranmer wrote: On 1/31/2013 8:26 PM, ISHIKAWA, Chiaki wrote: (2013/02/01 1:48), Joshua Cranmer wrote: On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote: Sorry, it may not have been ldap code (my memory is now hazy). But please take a look at this code. I am using comm-central code for development/debugging TB. https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53 This is NSS code, which is a separate codebase included in mozilla-central and updated periodically. Judging from the context, this is someone using the low 32 bits as a hash key; since it's a hashtable, I'm going to assume that it's expected to have some amount of collisions, so the conversion of a possibly-64-bit pointer to a 32-bit value is safe here. Yes, I was also expecting to see the collision resolution. But, if my reading was correct, in one place, I thought the equality of the hash value was deemed instantly to be the equality of the object. (That is why I thought something was fishy, and I assume that the coder thought it would work only under in 32bit address space. Thus the check for 32bit address space.) I should have raised the flag then and there. But I went on other things, and later when I learned the availability of 64bit version of TB, I was surprised. It could be that my reading of equality check may have been incorrect. Anyway, I assume that the code would bomb out by PR_ASSERT() if incorrect usage of this funciton in 64 bit address space is encountered at run time, and assuming that it has not happened to anybody (?), then probably this part of the code base is not used in production TB. That assert says that sizeof(PLHashNumber) == sizeof(PRUint32). Which is always true thanks to https://mxr.mozilla.org/comm-central/source/mozilla/nsprpub/lib/ds/plhash.h#18. Hmm. I will re-read this and make sure if I understand this correctly. TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 31/01/13 17:40, Robert O'Callahan wrote: Also, reducing the number of directories that are PGO/LTCG should mean that the rate of growth decreases proportionally. Even more than proportionally, if we flip our default for entirely new modules to be non-PGO/LTCG, as I assume we would. Profile guided PGO which does PGO only for files that show up as hotspots in the profile :-P ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
