I think there was also a performance reason: IIUC, the non-zero-cost exception handling strategy is baked into the Win32 ABI (https://www.microsoft.com/msj/0197/exception/exception.aspx) and thus enabling EH has a runtime cost for frames containing auto objects with destructors (which in modern SM is very common). I vaguely remember seeing a platform email thread about using EH a while back (>6 years) that measured the then-overhead in Gecko to be ~10%; I can't find the thread now. I talked to an engineer who worked on EH optimizations in MSVC and he said that there have been some 32-bit EH optimizations more recently but there is still runtime cost to having auto objects with destructors, so probably this is worth measuring again. Assuming we're able to move a large percentage of FF users to Win64 builds over the next year, then it seems like we'd care about this even less.
FWIW, though, I'd love to be able to use EH in SM. On Fri, Dec 18, 2015 at 9:55 PM, Jason Orendorff <jorendo...@mozilla.com> wrote: > I took the survey. > > I would be happy to use C++ exceptions in SpiderMonkey. The primary reason > we don't is historical. Converting a large, existing codebase to use > exceptions is a huge investment of time. (It also involves touching the > build system.) > > -j > > > > > > On Fri, Dec 18, 2015 at 7:28 AM, Rodrigo Bonifacio <rbonifacio...@gmail.com> > wrote: > >> Dear all, (apologies if you receive multiple copies) >> >> We are investigating the use of C++ exception handling constructs in well >> known open-source C++ systems, and have published some results in the last >> International Conference on Source Code Analysis and Manipulation [1] >> >> We are expanding this research to a broader community, so I kindly invite >> you to answer our new version of the survey at: >> >> https://www.surveymonkey.com/r/SXCB7WJ >> >> Sincerely, >> >> Rodrigo Bonifácio (on behalf of the authors of this research effort). >> >> [1] "The use of C++ exception handling constructs: A comprehensive study" >> http://dx.doi.org/10.1109/SCAM.2015.7335398 >> http://rbonifacio.net/papers/scam2015/rbonifacio-scam2015.pdf >> _______________________________________________ >> dev-tech-js-engine-internals mailing list >> dev-tech-js-engine-internals@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals >> > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
