On Thu, Sep 14, 2017 at 8:23 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote:
> Do I understand correctly that this is an address space issue only and > Windows doesn't actually physically map the pages belonging to the > stack until they are written to? That is, do I understand correctly > that there's no obstacle for growing the maximum stack size on 64-bit > Windows to the kind of numbers that Mac and Linux already have? > Correct, Windows reserves stack pages but does not commit them until the guard page is touched. > Is there a reason why a larger stack size is OK on 32-bit Linux but > wouldn't be OK on 32-bit Windows? > One difference is that Linux does not reserve stack pages (if the heap grows big it can use unused stack pages). > The failure mode of parts of email text silently going missing when > reading HTML email on a webmail app is *really* bad, so I'd like to > get it fixed in 57 instead of waiting for a task that touches many > more places getting completed further in the future. > We could get this fixed, then spend a few minutes in VMMap to check whether there are any long-lived beckground threads with excessive stack sizes that we could easily fix. I don't have a strong opinion on this btw - I just wanted to point out that it affects threads other than the main thread. Jan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
