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

Re: Proposal for fixing race conditions

From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date: Thu, 18 Jul 2013 15:05:28 -0400
Message-ID: <CANTur_537WBZQGm0TcmMjZnD8MmxrzZVyynLUf9QwwBxs-O5ZA@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
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>
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.

Received on Thursday, 18 July 2013 19:06:36 UTC

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