Re: [webkit-dev] Heads up: large typed array rewrite
Here's the status: it appears that the latest version of the patch only fails EWS because our dependency tracking for bindings code generation is borked. A clean build should unblock them. Mac, GTK, and EFL appear to build when you get a clean build. I'm getting help on Windows. Hopefully I'll get some help on Qt, also; but I think I covered my bases there. I plan to land this patch before 5PM PST tomorrow. Thanks for all of the help I've received so far! -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] Heads up: large typed array rewrite
And it's landed. Things seem more-or-less OK. I'll be around for the rest of the day to help with breakage. At this point, it just seems like there are some tests to rebase and some Windows stuff to fix. -Filip On Aug 15, 2013, at 12:21 AM, Filip Pizlo fpi...@apple.com wrote: Here's the status: it appears that the latest version of the patch only fails EWS because our dependency tracking for bindings code generation is borked. A clean build should unblock them. Mac, GTK, and EFL appear to build when you get a clean build. I'm getting help on Windows. Hopefully I'll get some help on Qt, also; but I think I covered my bases there. I plan to land this patch before 5PM PST tomorrow. Thanks for all of the help I've received so far! -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
[webkit-dev] Heads up: large typed array rewrite
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
Re: [webkit-dev] Heads up: large typed array rewrite
That is awesome! Good luck landing this tiny patch ;) Benjamin On Tue, 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
