[webkit-dev] Heads up: large typed array rewrite

[Benjamin Poulain]

That is awesome!
Good luck landing this tiny patch ;)

Benjamin


On Tue, Aug 13, 2013 at 11:19 AM, Filip Pizlo <fpizlo at 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130813/9a1f4c64/attachment.html>