On Thu, Feb 26, 2015 at 6:48 PM, Katelyn Gadd <[email protected]> wrote:
> In the past 'throw' statements have caused a deopt for the enclosing > function in v8 and spidermonkey. I think they still do in some > scenarios. I would assume that if a statement is able to throw the > enclosing function must have unwind logic and it could potentially > suppress inlining as well depending on how smart the VM is? > At least in SpiderMonkey, they don't cause a deopt anymore; only finally does (and exceptions that actually occur). More importantly, I would argue that performance concerns, even if they turn out to be real, shouldn't be the basis of a decision here. At least in strict mode, I can't think of any operations that would just silently let data fall under the table. E.g., setting a property on a frozen object throws. Silently swallowing the value on out-of-bounds writes to typed arrays would be an outlier here, and a dangerous one. > > On 25 February 2015 at 17:49, Mark S. Miller <[email protected]> wrote: > > Again, I don't understand this. Why would it make the normal case more > > expensive. The underlying detachment test must be there regardless, and > the > > only difference in behavior is what happens after that test fails. > > > > On Wed, Feb 25, 2015 at 5:05 PM, Jeff Walden <[email protected]> wrote: > >> > >> And expanding scope slightly: IntegerIndexedElementGet -- get -- throws > a > >> TypeError if the relevant typed array is detached, rather than just > >> returning |undefined| as the computed value. I understand there are > also > >> significant complaints about this, for similar reasons. > >> > >> Jeff >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
