Migrating to Visual Studio 2010
Kyle Huey
I just landed the fix for the last known bug in product code that stops us
from switching to MSVC 2010 (Bug 515492).
If RelEng can deploy MSVC 2010 SP1 to the builders in the next couple of
weeks I would like to try to change the official compiler for the next
release cycle (starting July 5th). This depends of course on how much
trouble we run into along the way :-) If deployment/test failures/perf
regressions slow us down this can always catch the next train.
Things we expect to pick up from MSVC 2010:
- Not being on a six year old compiler
- A modest perf improvement (maybe a couple percent).
- Fixes to known crashes with PGO (which should allow us to turn PGO back on
for the JS engine, which will pick up another 10-15% on Sunspider/etc)
- Fixes to various issues relating to crashreporter symbols that should
allow us to get better stacks (Bug 520651).
Other things worth noting:
- Downloading Windows debug builds from Tinderbox might be useful again
(since the debug CRT is non-redistributable, you must have the same version
of the compiler installed locally to run a debug build. This will be much
more bearable when we're on a version that people can get easily.)
- The CRT included with MSVC 2010 requires XP SP 2 or higher, so switching
compilers will end support for Windows 2000 and pre-SP2 versions of Windows
XP in official builds of Firefox. I expect that we will likely remove
support for Windows 2000 from Gecko itself shortly afterwards.
Questions/comments/concerns?
- Kyle
Ben Hearsum
> All,
>
> I just landed the fix for the last known bug in product code that stops us
> from switching to MSVC 2010 (Bug 515492).
>
> If RelEng can deploy MSVC 2010 SP1 to the builders in the next couple of
> weeks I would like to try to change the official compiler for the next
> release cycle (starting July 5th). This depends of course on how much
> trouble we run into along the way :-) If deployment/test failures/perf
> regressions slow us down this can always catch the next train.
When you say next release cycle, are you talking about 6, 7, or 8?
Kyle Huey
> When you say next release cycle, are you talking about 6, 7, or 8?
>
What would become Firefox 8.
- Kyle
Makoto Kato
Will other builders (Firefox Win64, Thunderbird and SeaMonkey) be
changed at same time?
-- Makoto
Neil
>- Downloading Windows debug builds from Tinderbox might be useful again (since the debug CRT is non-redistributable, you must have the same version of the compiler installed locally to run a debug build. This will be much more bearable when we're on a version that people can get easily.)
>
>
You can get all the old versions easily, just not obviously. In
particular, anyone wanting to run current Tinderbox debug builds and who
doesn't already have VC8 can simply install the Vista SDK.
--
Warning: May contain traces of nuts.
Kyle Huey
> Kyle,
>
> Will other builders (Firefox Win64, Thunderbird and SeaMonkey) be changed
> at same time?
>
> -- Makoto
They don't have to be, but they can be. I expect there will be some lag
there.
- Kyle
Kyle Huey
> - The CRT included with MSVC 2010 requires XP SP 2 or higher, so switching
> compilers will end support for Windows 2000 and pre-SP2 versions of Windows
> XP in official builds of Firefox. I expect that we will likely remove
> support for Windows 2000 from Gecko itself shortly afterwards.
>
Looking at the metrics data, we have just over 600k users peak on Windows
2000 during the middle of the week, across all Firefox versions.
- Kyle
Robert Kaiser
> - Fixes to known crashes with PGO (which should allow us to turn PGO back on
> for the JS engine, which will pick up another 10-15% on Sunspider/etc)
This is cool, but you know we didn't turn JS PGO off because there are
more crashes with it, right? We turned it off because different inlining
causes "crash signatures" to shift around to different ones, and that
mostly affects GC and MethodJIT crashes. Are you saying that MSVC 2010
will fix a lot of the GC and MethodJIT crashes? If not, it probably has
no large influence on being able to turn JS PGO back on, I fear.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
Robert Kaiser
> Kyle,
>
> Will other builders (Firefox Win64, Thunderbird and SeaMonkey) be
> changed at same time?
No idea about Thunderbird, but IIRC, Justin (Callek), the SeaMonkey
RelEng guy, said he'd like to install it (if SeaMonkey can obtain MSVC
2010 and the rights to use it), but there were concerns that it can't be
deployed to VMs somehow and SeaMonkey only has its 5 VMs right now for
Windows builds.
Kyle Huey
> Kyle Huey schrieb:
>
> - Fixes to known crashes with PGO (which should allow us to turn PGO back
>> on
>> for the JS engine, which will pick up another 10-15% on Sunspider/etc)
>>
>
> This is cool, but you know we didn't turn JS PGO off because there are more
> crashes with it, right?
>
Yes, we did. See https://bugzilla.mozilla.org/show_bug.cgi?id=605033, where
we turned off PGO specifically because we had a reproducible crash that was
bisected back to turning PGO on. Comments 24, 25, 30, and 46 are likely of
particular interest there.
- Kyle
Robert Kaiser
Then you also read the analysis that we did not see any change at all in
crash volume from turning it off and that drivers decided that we'll
need some significant changes in those top JS-related crashes that move
around with PGO before we can turn it on again. You surely also have
read my comments there, and those of drivers.
I'm not saying that we shouldn't switch to MSVC 2010, I'm just saying we
probably won't just be able to turn JS PGO on once that's done.
Benjamin Smedberg
>
> Then you also read the analysis that we did not see any change at all
> in crash volume from turning it off and that drivers decided that
> we'll need some significant changes in those top JS-related crashes
> that move around with PGO before we can turn it on again. You surely
> also have read my comments there, and those of drivers.
good reason to keep PGO off: PGO by its nature will aggressively inline
things, and this will result in more variable signatures sometimes.
But also, VC2010 PGO produces better stack traces from inlined
functions, so it may not be a huge issue.
--BDS
Chris AtLee
How many of those users are on Firefox 4.0.1 or 5?
Kyle Huey
> Kyle Huey schrieb:
>
>> On Wed, Jun 29, 2011 at 10:43 AM, Robert Kaiser<ka...@kairo.at> wrote:
>>
>> Kyle Huey schrieb:
>>>
>>> - Fixes to known crashes with PGO (which should allow us to turn PGO
>>> back
>>>
>>>> on
>>>> for the JS engine, which will pick up another 10-15% on Sunspider/etc)
>>>>
>>>>
>>> This is cool, but you know we didn't turn JS PGO off because there are
>>> more
>>> crashes with it, right?
>>>
>>>
>> Yes, we did. See https://bugzilla.mozilla.org/**show_bug.cgi?id=605033<https://bugzilla.mozilla.org/show_bug.cgi?id=605033>,
>> where
>> we turned off PGO specifically because we had a reproducible crash that
>> was
>> bisected back to turning PGO on. Comments 24, 25, 30, and 46 are likely
>> of
>> particular interest there.
>>
>
> Then you also read the analysis that <snip> drivers decided that we'll need
> some significant changes in those top JS-related crashes that move around
> with PGO before we can turn it on again. You surely also have read my
> comments there, and those of drivers.
>
I didn't read anything of the sort. Every discussion in that bug is about
crash numbers or "instability" ....
In comment 45 you recommended turning it back on and in comment 46 I said we
should hold off for the compiler upgrade ... and now you're taking the
opposite position based on statements that have never been made in the bug.
- Kyle
Robert Kaiser
> I do not think that "some crash signatures will become variable" is a
> good reason to keep PGO off: PGO by its nature will aggressively inline
> things, and this will result in more variable signatures sometimes.
Tell that to drivers... ;-)
(That said, we should get better instrumentation so something like that
doesn't randomly change signatures...)
> But also, VC2010 PGO produces better stack traces from inlined
> functions, so it may not be a huge issue.
That sounds promising, I hope we can used that for not losing track of
where the actual crashes happen (well, the ones we are concerned about
are mostly GC and MethodJIT, which happen somewhere else than the
current signatures tells us anyhow).
Asa Dotzler
> - The CRT included with MSVC 2010 requires XP SP 2 or higher, so switching
> compilers will end support for Windows 2000 and pre-SP2 versions of Windows
> XP in official builds of Firefox. I expect that we will likely remove
> support for Windows 2000 from Gecko itself shortly afterwards.
I believe should not be a developer or rel eng only discussion and needs
wider input than what's likely to be found on dev.platform.
Which platforms we will un-support must include input from the at least
(additionally) the Product team and so I think this part of the
discussion has to happen on .planning.
- A
Asa Dotzler
> - The CRT included with MSVC 2010 requires XP SP 2 or higher, so switching
> compilers will end support for Windows 2000 and pre-SP2 versions of Windows
> XP in official builds of Firefox. I expect that we will likely remove
> support for Windows 2000 from Gecko itself shortly afterwards.
I believe should not be a developer or rel eng only discussion and needs
Kyle Huey
I have a few things to follow up on first, but a .planning post specifically
about the older versions of Windows is coming in the next couple days.
- Kyle