On Wed, Sep 13, 2017 at 5:19 PM, Jan de Mooij <jdemo...@mozilla.com> wrote: > On Wed, Sep 13, 2017 at 10:44 AM, Henri Sivonen <hsivo...@hsivonen.fi> > wrote: >> >> 3) Increase the run-time stack size on Windows such that 1026-deep >> display: table-cell doesn't overflow the stack. > > > On Windows, threads that are created without an explicit stack size also use > the executable's stack size. So increasing our stack size will also affect a > bunch of other threads and we risk an increase in virtual memory OOMs on > Win32.
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? Is there a reason why a larger stack size is OK on 32-bit Linux but wouldn't be OK on 32-bit Windows? (Seems kinda weird that both defaults would just happen to be exactly perfect even when they are so different.) How about we increase the stack size on 64-bit Windows to accommodate 1026-deep display: table-cell as on Linux and Mac and increase the stack size on 32-bit Windows by just 20% to be able to deal with 600-deep (513 plus a little to accommodate innerHTML) display: block? (After all, one can already overflow the stack on 32-bit Windows with fewer than 200 display: table-cells, so the status-quo precedent doesn't require us to make the depth limit prevent overflow on 32-bit Windows in the all-table-cell case.) It would be sad not to be able to match Blink's HTML parser-level magic number on 32-bit Windows, but Blink's magic number is too close to what the current stack size on 32-bit Windows happens to allow, so we'd need to grow the stack limit at least a little bit. Do Windows anti-virus programs inject stuff on the stack and steal stack space compared to my clean (Windows 10's Windows Defender) test system? > I filed bug 1257522 [0] two years ago to pass an explicit stack size > for a number of background threads we create in Gecko, it would be nice to > fix that first. 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. On Thu, Sep 14, 2017 at 12:38 AM, Mike Hommey <m...@glandium.org> wrote: > On Wed, Sep 13, 2017 at 10:03:55AM -0700, Eric Rahm wrote: >> Jan is right, increasing the stack size for all threads would cause a very >> large memory regression. Lets not do that ;) Selectively increasing might >> make sense but we'd need to keep an eye on how large of an increase we're >> expecting. > > We could also move the main thread loop to a thread that we create with > a stack size we want, and leave the original main thread just waiting > for it (joining it). Does Quantum DOM already mean that the threads that the frame constructor runs on are explicitly-spawned and not the system-spawned main thread? Are Quantum DOM main threads created in such a way that it would be easy to add an explicit stack size request? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
