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 <[email protected]> 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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
