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.

--
Ehsan
<http://ehsanakhgari.org/>
Received on Thursday, 18 July 2013 19:06:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC