On 2015/05/05 17:52:43, binji wrote:
On 2015/05/05 16:14:22, binji wrote:
> On 2015/05/05 16:06:19, jochen wrote:
> > If a SAB behaves like an AB of you don't use the correct atomics, we
could
> > basically allow atomic operations on ABs as well - since they can't be
shared,
> > nothing can go wrong.
>
> True.
>
> >
> > It sounds like all we need is a bunch of constructors that create
regular
ABs
> > and set a bit in addition that this AB can be shared.
>
> Yes, that is how ncbray@'s prototype worked. But if a SAB is just an AB,
then
it
> means that a SAB can be passed to APIs that expect ABs, which we don't
want.
> Similarly, we don't want all the ArrayBuffer APIs to be available to SAB
(e.g.
> ArrayBuffer.slice, ArrayBuffer.transfer, etc.)
>
> Or are you thinking that SAB is a type that is only available to Blink,
not
v8?
> Perhaps that is possible -- though I'm not sure how the v8 type <->
Blink
type
> coercion works if the v8 type is shared between two Blink types.
I should also mention that we may need to store a mutex per SAB to handle
atomic
accesses on architectures that don't support 64-bit atomics. Similarly,
we may
need a data structure on the SAB to track futex waiters. There are other
possible implementations, but in general I think we will need some
additional
data structures on SAB types. We probably don't want to require those for
ArrayBuffers as well.
>
> >
> > Then we only need to check this bit when we need to decide whether to
neuter
> or
> > share the AB for postMessage.
I think the complexity of this is getting a bit out of hands. Could we
possibly
have a separate design document which outlines what needs to be done?
The document should describe at least the following:
1. Representation of SAB in v8.
2. Compilation of non-atomic accesses to SAB. (Probably just like normal
accesses to AB, but if the SAB have different map as in the current
version, one
has to be careful about map checks/polymorphism in hydrogen and ICs.)
3. Compilation of atomic accesses to SAB. This should discuss all the
compilers:
full code, hydrogen and turbofan. My guess is we would be fine with having
runtime functions for full code and hydrogen, but turbofan needs to have
optimized version. This should also discuss architecture specific details
(such
as implementation on architectures without 64-bit atomic instructions).
4. Compilation of futexes.
5. Discussion of neutering and friends.
6. API design, interface to the rest of chrome.
I am sure I am missing other important aspects.
https://codereview.chromium.org/1069883002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
