{"id":120,"date":"2013-01-22T17:37:15","date_gmt":"2013-01-22T17:37:15","guid":{"rendered":"http:\/\/blog.mozilla.org\/nfroyd\/?p=120"},"modified":"2013-01-22T17:37:15","modified_gmt":"2013-01-22T17:37:15","slug":"analyzing-linker-max-vsize","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nfroyd\/2013\/01\/22\/analyzing-linker-max-vsize\/","title":{"rendered":"analyzing linker max vsize"},"content":{"rendered":"

mozilla-inbound is currently approval-only due to issues with Windows PGO builds.\u00a0 The short explanation is that we turn on aggressive code optimization for our Windows builds.\u00a0 This aggressive code optimization causes the linker than comes with Visual Studio to run out of virtual memory.\u00a0 The current situation is especially problematic because we can’t increase the amount of virtual memory the linker can access (unlike last time, where we “just” moved the builds to 64-bit machines).<\/p>\n

We don’t really have a good handle on what causes these issues (other than the obvious “more code”), but at least we are tracking the linker’s vsize<\/a> and we’ll soon have pretty pictures<\/a> of the same.\u00a0 We hadn’t expected to have to deal with this problem for several more months.\u00a0 The graph below helps explain why we’re hitting this problem a little sooner than before.\u00a0 The data for this graph was taken from the Windows nightly build logs.<\/p>\n

\"Win32<\/a><\/p>\n

Notice the massive spike in October, as well as the ~100MB worth of growth in early January.\u00a0 While the data is not especially fine-grained (nightly builds can include tens of changesets, and we’d really like information on the vsize growth on a per-changeset basis), looking at the biggest increases over the last ten months might prove helpful.\u00a0 There have been ~300 nightly builds since we started recording data; below is a list of the top 20 daily increases in linker max vsize.\u00a0 The date in the table is the date the nightly build was done; the newly-included changeset range is linked to for your perusal.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Nightly build date<\/th>\nvsize increase (MB)<\/th>\n<\/tr>\n
2012-05-18<\/a><\/td>\n282.363281<\/td>\n<\/tr>\n
2012-10-06<\/a><\/td>\n103.609375<\/td>\n<\/tr>\n
2012-10-08<\/a><\/td>\n90.769531<\/td>\n<\/tr>\n
2013-01-10<\/a><\/td>\n49.699219<\/td>\n<\/tr>\n
2012-06-02<\/a><\/td>\n49.199219<\/td>\n<\/tr>\n
2012-10-19<\/a><\/td>\n32.976562<\/td>\n<\/tr>\n
2012-12-25<\/a><\/td>\n32.332031<\/td>\n<\/tr>\n
2013-01-06<\/a><\/td>\n32.015625<\/td>\n<\/tr>\n
2013-01-20<\/a><\/td>\n30.144531<\/td>\n<\/tr>\n
2013-01-22<\/a><\/td>\n27.222656<\/td>\n<\/tr>\n
2012-10-04<\/a><\/td>\n19.273438<\/td>\n<\/tr>\n
2012-05-10<\/a><\/td>\n18.234375<\/td>\n<\/tr>\n
2012-11-23<\/a><\/td>\n17.937500<\/td>\n<\/tr>\n
2012-08-03<\/a><\/td>\n17.738281<\/td>\n<\/tr>\n
2013-01-07<\/a><\/td>\n17.671875<\/td>\n<\/tr>\n
2012-09-08<\/a><\/td>\n17.386719<\/td>\n<\/tr>\n
2012-12-23<\/a><\/td>\n17.269531<\/td>\n<\/tr>\n
2012-12-27<\/a><\/td>\n17.156250<\/td>\n<\/tr>\n
2012-11-11<\/a><\/td>\n17.085938<\/td>\n<\/tr>\n
2012-12-06<\/a><\/td>\n17.003906<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Mike Hommey suggested that trying to divine the whys and hows of extra memory usage would be a fruitless endeavor. Looking at the above pushlogs, I am inclined to agree with him. There’s nothing in any of them that jumps out. I didn’t try clicking through to individual changesets to figure out what might have added large chunks of code, though.<\/p>\n","protected":false},"excerpt":{"rendered":"

mozilla-inbound is currently approval-only due to issues with Windows PGO builds.\u00a0 The short explanation is that we turn on aggressive code optimization for our Windows builds.\u00a0 This aggressive code optimization causes the linker than comes with Visual Studio to run out of virtual memory.\u00a0 The current situation is especially problematic because we can’t increase the […]<\/p>\n","protected":false},"author":320,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/120"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/users\/320"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/comments?post=120"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/120\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/media?parent=120"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/categories?post=120"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/tags?post=120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}