On Jul 18, 2013, at 12:05 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
> On Thu, Jul 18, 2013 at 3:03 PM, Jer Noble <jer.noble@apple.com> wrote:
>
>
> On Jul 18, 2013, at 11:58 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
>
>> 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.
>
> This still implies either a memory or CPU cost in tracking the allocations sites for every ArrayBuffer.
>
> Absolutely! Neutering an array buffer is not a free operation. I was just trying to say that the pathological behavior that JSC has is a bug in JSC which can be fixed, given the fact that there is at least one other implementation which implements the same concept without suffering from this problem.
This is an implementation choice. Right now, neutered buffers are very rare, so JSC has optimized the non-neutering case. It sounds like SpiderMonkey has chosen a different optimization strategy, trading an upfront cost (tracking and checking allocation sites) for limiting the cost of the pathological neutering case.
I would prefer to not make neutering any more common, not only because JSC is already heavily optimized for that case, but because neutering violates a design principle of ArrayBuffers, that their length is immutable.
As such, I would like to explore non-neutering options to solve the data race issue, if it's resolved that the data race issue needs solving.
-Jer