W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: Proposal for fixing race conditions

From: Jer Noble <jer.noble@apple.com>
Date: Thu, 18 Jul 2013 12:03:47 -0700
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Marcus Geelnard <mage@opera.com>, WG <public-audio@w3.org>, "robert@ocallahan.org" <robert@ocallahan.org>, "K. Gadd" <kg@luminance.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
Message-id: <D00CB6CD-4FDF-4D89-B25C-C658DAB9395E@apple.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>

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.


Received on Thursday, 18 July 2013 19:04:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC