[webkit-dev] Uint8ClampedArray: subtype of Uint8Array or not? (Was: Heads up: large typed array rewrite)

Wed Aug 14 11:19:41 PDT 2013

The spec (http://www.khronos.org/registry/typedarray/specs/latest/) says "Constructors: None”, looks like FireFox is right, we should probably just remove this.

G.

On Aug 14, 2013, at 12:34 AM, Filip Pizlo <fpizlo at apple.com> wrote:

> And on a similar note: ArrayBufferView.  What's that all about?
> 
> Previously, WebKit had ArrayBufferView as a prototype and constructor that wasn't instantiable, allowing for things like:
> 
> (new Int8Array() instanceof ArrayBufferView) === true
> 
> but not:
> 
> new ArrayBufferView()  // error!
> 
> Firefox has no notion of ArrayBufferView.  I.e. you get a reference error if you mention it.  I tend to think that having ArrayBufferView as a JS-visible concept is strange.
> 
> -Filip
> 
> 
> On Aug 14, 2013, at 12:31 AM, Jochen Eisinger <jochen at chromium.org> wrote:
> 
>> Adding Dmitry who recently updated the V8/blink implementation.
>> 
>> -jochen
>> 
>> 
>> On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo <fpizlo at apple.com> wrote:
>> What WebKit previously did: Uint8ClampedArray is a subtype of Uint8Array, i.e. Uint8ClampedArray.prototype.__proto__ === Uint8Array.prototype.
>> 
>> I believe that Chrome still does what WebKit does.
>> 
>> What Firefox does: Uint8ClampedArray is not a subtype of Uint8Array, i.e. Uint8ClampedArray.prototype.__proto__ === Object.prototype.
>> 
>> What http://www.khronos.org/registry/typedarray/specs/latest/ says: Uint8ClampedArray implements ArrayBufferView; but that says nothing about its subtype relationship, or lack thereof, with Uint8Array.
>> 
>> I prefer the Firefox semantics.  Any objections?
>> 
>> -Filip
>> 
>> 
>> On Aug 13, 2013, at 11:19 AM, Filip Pizlo <fpizlo at apple.com> wrote:
>> 
>>> Hi everyone!
>>> 
>>> For the past week or so I've been working on making typed arrays faster, use less memory, and GC better.  It involves moving typed arrays entirely into JSC, and rewriting them so that they benefit from JSC object model optimizations.
>>> 
>>> Link: https://bugs.webkit.org/show_bug.cgi?id=119064
>>> 
>>> The short story is, if you're not on the Mac port, then I'll try to do my best to make things work but I'm probably going to make some mistakes.  I'm probably about 48 hours away from landing this and I'll try to make myself available to fix any fall-out.  The things I'm most likely to get wrong are: ensuring that the various code generators work on all build systems; ensuring that the ~20-some files I've added and the ~20-sime files I've deleted, are actually added/deleted correctly on all builds; and making sure that some of the crazy template hacks that I've used work on all compilers.
>>> 
>>> Why this is all worth it:
>>> 
>>> It makes typed arrays faster: you can now allocate typed arrays up to 8x faster if they're small, and up to 6x faster if they're big.  Neutering no longer requires walking all worlds. Wrapping and unwrapping an array buffer no longer requires hash look-ups for the normal world.  And some other stuff, too.
>>> 
>>> It makes typed arrays use less memory: previously a typed array could use as many as 7 objects for each allocation; at best you'd get 5 (JS array buffer view wrapper, native array buffer view wrapper, weak handle to link the two, native array buffer, native array buffer contents).  Now, it takes just 2 objects in the common case (JS array buffer view and a copy-space backing store) and 3 in the case of large ones (JS array buffer view, weak handle for a finalizer, and a malloc'd backing store).  You'll still get all of the crazy objects - at most 6 of them - if you use the full power of typed array APIs.  With all of this in place, a typed array carries only 32 bytes of overhead on 64-bit systems and 20 bytes of overhead on 32-bit systems.  It was *a lot* more than that before.
>>> 
>>> It makes typed arrays manage memory properly: previously the GC didn't know that typed arrays use memory.  So, although the GC could free the memory that typed arrays used, it wouldn't kick in properly in some cases.  See https://bugs.webkit.org/show_bug.cgi?id=119049 and https://bugs.webkit.org/show_bug.cgi?id=114824.  This patch fixes these issues comprehensively.
>>> 
>>> It makes the code more hackable: previously any attempt to optimize any typed array hack required grappling with binding code generation, layering violations that exposed the typed arrays to JSC JITs despite not being defined in JSC, and a grab-back of helper code that the bindings magically invoked.  There was a lot of duplicated code to deal with the various types of typed arrays.  Now, typed arrays are all templatized; you usually only write a piece of code once thanks to the wonders of template polymorphism.
>>> 
>>> This also fixes a bunch of semantics issues, with how typed array fields work in JS and when/where exceptions ought to be thrown.  In this regard, I'm basically attempting to match Firefox behavior since that's where the standards appear to be going.
>>> 
>>> I hope that I get all of this to work on all platforms on the first try.  If I don't, I apologize in advance, and I'll try to be around to help the fall-out.
>>> 
>>> -Filip_______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130814/95d6a2b7/attachment.html>