Seems like a bug. You can just profile whether the exceptional path was ever taken; if it wasn't then speculate that accesses are in-bounds. Boom, you have a fast in-bounds check and the optimizing JIT doesn't have to know anything about what happens on out-of-bounds (i.e. it could throw exceptions, call functions, or activate toaster ovens - it don't matter).
I think that throwing on out-of-bounds assignment makes sense in strict mode. I'm in favor of that behavior. -Filip > On Feb 25, 2015, at 4:40 PM, Jeff Walden <[email protected]> wrote: > > Currently, the behavior of IntegerIndexedElementSet is to return false if the > index being set is outside the array bounds. This return-false directly > feeds into the result of [[Set]] on a typed array. The result is that in > strict mode code, setting an out-of-bounds array element throws a TypeError. > > I've heard claims from other SpiderMonkey implementers that this requirement > makes it difficult to implement high-performance JIT optimizations for code > that assigns into typed arrays, except in the case that the array length is > observable in context, the typed array never escapes anywhere, its backing > ArrayBuffer never escapes anywhere, etc. Restrictions that generally aren't > very easy to determine with local information observable by a JIT. And while > quite often such high-performance code isn't strict mode code, it's doubtful > that will be true far into the future. > > From that point of view, it would be better if IntegerIndexedElementSet just > returned true in this case -- indicate success without doing anything. What > are the compelling reasons to not do this? > > Jeff > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
