Adding Dmitry who recently updated the V8/blink implementation. -jochen
On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo <[email protected]> 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 <[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 > >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
