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 <[email protected]> wrote: > 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
