Once bug 742491 lands, we'll have a (hopefully) thread-safe implementation of WindowsDllInterceptor::AddHook for the functions that AvailableMemoryTracker overrides. But we won't have a similar fix for x86-64. Until we do, we should just disable the AvailableMemoryTracker there. It's doing minimal good, anyway.
Try run for 2c455f12a9f2 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=2c455f12a9f2 Results (out of 50 total builds): success: 43 warnings: 7 Builds (or logs if builds failed) available at: http://firstname.lastname@example.org
Created attachment 617482 [details] [diff] [review] Patch v1
What's the distribution of total RAM like for 32-bit operating systems vs 64-bit operating systems? I assume Telemetry provides the necessary data. I see quite a few 64-bit machines (with Windows 7 64-bit) sold with 2 GB of RAM. I don't know if that is less than your definition of "fair bit of physical memory".
This wasn't really a decision based on hardware specs. I disabled a fringe feature (low-memory detection) in favor of stability. I have no way to make the code, as it exists, thread-safe on 64-bit. If we figure it out (it's a fair bit of tricky work, and win64 isn't even tier 1), I'll gladly turn the feature back on.
For the sake of completeness, I'm looking for our telemetry on physical memory. I could have sworn we collect it, but I'm not seeing it in the dashboard.
We do collect physical memory size, but we don't surface it in the telemetry dashboards. :(