Re: Proposal for fixing race conditions

On Thu, Jul 18, 2013 at 3:11 PM, Jer Noble <jer.noble@apple.com> wrote:

>
> 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.
>

Fair enough.  I don't know what the cost of the two approaches is exactly,
but there are definitely some trade-offs here.


> 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.
>

With more APIs being exposed to Web Workers in the future, the platform is
definitely moving towards neutering becoming a common operation.  (I'm not
saying this to advocate for using neutering in Web Audio, it's just that it
seems this will be a losing battle for JSC...)


> 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.
>

FWIW the neutering solution was only suggested in order to maintain API
backwards compatibility.  The alternative to that would be to copy the
contents of the AudioBuffers when, for example, you set
AudioBufferSourceNode.buffer, which is objectively worse, and it's also
weird semantic wise (node.buffer = buf; var isEqual = node.buffer === buf;,
isEqual will be false.)

The alternative solution (the immutable AudioBuffers solution) is, IMO, a
more elegant solution (it's what I would have done if I were designing the
API today.)

Or we could go with a hybrid approach of not breaking existing code with
the neutering semantics, and design an API based on the second solution and
then advertize the first API as legacy, etc.

--
Ehsan
<http://ehsanakhgari.org/>