On Thu, Jul 18, 2013 at 2:48 PM, Jer Noble <jer.noble@apple.com> wrote: > > > On Jul 18, 2013, at 11:41 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com> > wrote: > > The problem Jer described is a bug in JavascriptCore. There is no reason > why it should be an issue in other JS engines, and I know that it is not an > issue in SpiderMonkey (not sure about v8). I think this is a bug that JSC > needs to fix anyway, since neutering is already a concept used in other > parts of the web platform. > > > There is no "fix". JSC can assume that the length of ArrayBuffers is > immutable, and those assumptions are invalidated by neutering. Once /any/ > neutering happens, this invalidates the assumptions for every ArrayBuffer > in existence, forcing JSC to do a neuter-check or a length-check for every > ArrayBuffer upon access. > > It may be the case that SpiderMonkey and V8 check to see if an ArrayBuffer > has been neutered before each and every access into that ArrayBuffer, but > that just means those engines already suffer from this neutering > performance penalty. > I just checked with SpiderMonkey folks. The way that SM handles this is by separating the typed array "type" information based on the allocation site, and only deoptimize the access for typed arrays that share the same "type", so if you have a typed array that gets neutered in location X in your code, it will only deoptimize the accesses for typed arrays coming from that place in the code. So, no, SM doesn't suffer from the same problem as JSC does, and I see no reason why this cannot be fixed in JSC (well, other than engineering time, the complexity of the fix and all of the other usual suspects.) But like I said, this is already affecting other parts of the web platform anyway. -- Ehsan <http://ehsanakhgari.org/>
Received on Thursday, 18 July 2013 18:59:45 UTC