[webkit-dev] Uint8ClampedArray: subtype of Uint8Array or not? (Was: Heads up: large typed array rewrite)
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 fpi...@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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Uint8ClampedArray: subtype of Uint8Array or not? (Was: Heads up: large typed array rewrite)
Adding Dmitry who recently updated the V8/blink implementation. -jochen On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo fpi...@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 fpi...@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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Uint8ClampedArray: subtype of Uint8Array or not? (Was: Heads up: large typed array rewrite)
Glad to hear it. That's the direction I was hoping for. -F On Aug 14, 2013, at 12:34 AM, Dmitry Lomov dslo...@chromium.org wrote: For in the upcoming ES6 standard a decision has been made that Uint8ClampedArray will not inherit from Uint8Array. Latest Khronos spec reflects that as well. In Chrome M30 we have updated this, so our implementation matches the spec and what Firefox did. Regards, Dmitry On Wed, Aug 14, 2013 at 9:31 AM, Jochen Eisinger joc...@chromium.org wrote: Adding Dmitry who recently updated the V8/blink implementation. -jochen On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo fpi...@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 fpi...@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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing
Re: [webkit-dev] Uint8ClampedArray: subtype of Uint8Array or not? (Was: Heads up: large typed array rewrite)
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 fpi...@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 joc...@chromium.org wrote: Adding Dmitry who recently updated the V8/blink implementation. -jochen On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo fpi...@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 fpi...@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
