bug 709193 makes it very hard for us to do development. We should monitor the peak virtual memory usage of link.exe when we're linking libxul the final time so we have some sort of benchmark for how close we are to the danger zone, so we can at least make reasonable decisions about what we're doing.
Assignee: nobody → ted.mielczarek
I have this mostly working, just testing it currently.
This seems to do the trick locally. I've pushed it to try just to make sure it doesn't screw anything up there, but I think this should do what we want. It currently prints the measurement to stdout, as well as writing it to $objdir/toolkit/library/linker-vsize. https://tbpl.mozilla.org/?tree=Try&rev=a076385f7cb7
Attachment #581941 - Flags: review?(catlee)
Comment on attachment 581941 [details] [diff] [review] Measure peak virtual memory usage of link.exe, print and output to a file Review of attachment 581941 [details] [diff] [review]: ----------------------------------------------------------------- looks good!
Attachment #581941 - Flags: review?(catlee) → review+
Status: NEW → ASSIGNED
Should we make the build automatically go orange if the linker memory usage goes over some danger threshold? Seems like that would be helpful to warn us if we're about to hit the wall.
> Should we make the build automatically go orange See bug 710840 comment 1 :-)
On the last pgo build on inbound currently (7a0d03046d42): linker max virtual size: 2266345472 That seems reaaaally low. It would be good to try on one of the changesets that was failing to link.
On the changeset I pushed to try (which was about a month out of date), it was ~2.83GB. We can certainly push this to try on top of some of the failing changesets to get data points, but I'm fairly confident in the measurement here. It matched Process Explorer's number exactly (which makes sense because it's calling the exact same API).
Which suggests we have managed to reduce the memory usage by more than 700MB, that's an order of magnitude more than what Kyle has seen.
I'm tempted to say this would be interesting to land on beta and aurora.
On 718a7411a72b, it measured at 2265296896, which is exactly 1MB more, which seems like pretty decent consistency.
Comment on attachment 581941 [details] [diff] [review] Measure peak virtual memory usage of link.exe, print and output to a file This is a build-system-only change that simply adds reporting to the amount of virtual memory used by the linker during our PGO builds. Since exhausting the virtual address space has disastrous consequences, this should give us fair warning if we're about to destroy our ability to ship Firefox.
(In reply to Mike Hommey [:glandium] from comment #9) > Which suggests we have managed to reduce the memory usage by more than > 700MB, that's an order of magnitude more than what Kyle has seen. I would find it incredibly hard to believe that we've reduced linker memory usage by 700 MB.
Another data point that would be interesting to have (but not necessary tracked, Try is probably enough) is the value for non-PGO builds.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
Turns out that gavin broke PGO builds in an insidious way in bug 696436 (bug 711478), so I can't give you the non-PGO number, but I can tell you that those numbers above are "PGO without any profiling data", which is why they're much lower than expected. A non-broken inbound run measured at 3027816448, which is 2.82GB, which sounds a lot more reasonable. (If you wanted to test this on non-PGO runs, you could just drop the ifdefs around the Makefile hunk in this patch.)
Comment on attachment 581941 [details] [diff] [review] Measure peak virtual memory usage of link.exe, print and output to a file [Triage Comment] Approved for Aurora and Beta.
Marking qa- as I don't think this is something QA needs to verify. Please mark qa+ if this is not the case.
You need to log in before you can comment on or make changes to this bug.