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

[Filip Pizlo]

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

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