JS Team Newsletter 7/28/2011
David Mandelin
This first one covers roughly the previous 2 weeks. It seems pretty long
so I'll try for a weekly update.
If I missed any big news, please post it as a reply. Also, in the future
feel free to email me about anything you'd like included in the next
newsletter.
*New Hire*
Marty Rosenberg has joined the JS team to work on ARM compiler
performance. He's starting out by implementing typed array ICs for ARM
and finding opportunities to improve the JM ARM backend. Welcome, Marty!
https://bugzilla.mozilla.org/show_bug.cgi?id=649202
https://bugzilla.mozilla.org/show_bug.cgi?id=674274
*Changes to SpiderMonkey that might affect you*
- Chris Leary redid the option parser (bug 668095). He removed some of
the little-used options while he was at it. If you needed one of them,
file a bug to get it back.
*Project Status Updates*
IonMonkey
- David Anderson updated the IonMonkey feature page with detailed
planning info, including major chunks of work to be done in the near
future.
https://wiki.mozilla.org/Platform/Features/IonMonkey
- Thanks in part to trampolines written by Andy Scheff (bugs 670819 and
670820) , IM recently ran its first program, a tiny program with a &
(bug 670816).
- David Anderson is making progress on bailouts from optimized native
code (bug 670827). Optimized native code is compiled for a certain set
of types for each value. If those assumptions don't hold (e.g., an
integer + overflows when it was predicted not to), then the code must
jump to a handler that can continue execution with the actual types, and
possibly also trigger recompilation. Basic bailouts will take us to the
interpreter.
Debug Object
- Jim Blandy and Jason Orendorff are getting close to landing. Most of
the patches have now been reviewed. Jason blogged about the prompt reviews:
http://blog.mozilla.com/jorendorff/2011/07/25/why-fast-reviews-happen/
GC
- Bill McCloskey is getting close on Incremental GC: write barrier
performance is now good in the benchmarks, and it can be tuned down to
pause times of 1ms or less.
- Bill has also been landing diagnostics for the GC topcrashes (bug
670702), which are among the most common JS topcrashes and are very hard
to debug. The most promising lead so far has been the discovery that
some scripts are getting double-destroyed. Bug 673625 is trying to
collect more data on that.
*Other News*
- Dave Mandelin gave a reprise of the "Know Your Engines" talk at Meebo
last Monday. There are a few people there interested in contributing to
performance tools--JS performance and also DOM performance are major
concerns to them. A couple of new ideas came out of our discussion: an
IC profiler, to show which property access sites are getting IC'd and
why or why not; and a debugging tool to show whether an array is dense
or sparse, because denseness is so important for performance but
currently not directly visible to the user in any way.
- Nick Nethercote continues to improve about:memory, with even more
detail now on JS. He also discovered that often as little as 30% of the
JS heap is live data--the rest is fragmentation (see bug 669611). There
are a few bugs on file to try simple things to improve this (bugs 671702
and 669245), but generational GC and compacting GC are the best
candidates for a definitive fix.
*Key landings not mentioned above*
title: Workers: Make one OS thread and JS runtime per worker, and lose
XPConnect
author: Ben Turner
link: https://bugzilla.mozilla.org/show_bug.cgi?id=649537
notes: I'm not an XPConnect expert, but I guess this greatly
simplifies DOM<->SpiderMonkey communication and removes the need for
XPConnect there. This will help us greatly simplify things in SM as
well: We can now make JSRuntime single-threaded, and that in turn lets
us do compartment-per-global.
title: Update Unicode Table
author: Tom Schuster
link: https://bugzilla.mozilla.org/show_bug.cgi?id=652771
notes: Excellent to see this. Our old Unicode support was derived from
an old JDK, so it was about 10 years old by this point, had some errors,
and didn't support some key concepts like middle-casing. This patch
redid all the Unicode support and (almost completely) fixes our Unicode
compatibility.
title: XPCWrappedNative keys can disappear from WeakMaps
author: Andrew McCreight
link: https://bugzilla.mozilla.org/show_bug.cgi?id=655297
notes: This was blocking work on DOM tree editing in devtools, so it's
great to see it cleared. This bug solves only part of the
problem--followup work will be in bug 673468.
title: Reimplement watchpoints using a JSObject bit
author: Jason Orendorff
link: https://bugzilla.mozilla.org/show_bug.cgi?id=637985
notes: The old watchpoint implementation was tricky and a common source
of regressions, so the simplification here is much appreciated.
title: JM: getelement pic for arguments
author: Tom Schuster
link: https://bugzilla.mozilla.org/show_bug.cgi?id=616744
notes: Makes args[i] fast in JM; no data on speedups, but might help us
a bit with web frameworks (jQuery et. al.), which tend to use |arguments|.
title: Make it more obvious which bits in JSObject::flags are up for grabs
author: Jeff Walden
link: https://bugzilla.mozilla.org/show_bug.cgi?id=673647
notes: jsobj.h now makes it clear exactly which flag bits are in use.
Nicholas Nethercote
> Here's the first JS team update newsletter, as suggested by jorendorff.
Thanks! Nice to read this.
> title: Workers: Make one OS thread and JS runtime per worker, and lose
> XPConnect
> author: Ben Turner
> link: https://bugzilla.mozilla.org/show_bug.cgi?id=649537
> notes: I'm not an XPConnect expert, but I guess this greatly
> simplifies DOM<->SpiderMonkey communication and removes the need for
> XPConnect there. This will help us greatly simplify things in SM as
> well: We can now make JSRuntime single-threaded, and that in turn lets
> us do compartment-per-global.
It also fixed some common zombie compartments caused by web workers.
Known examples were at coffeekup.org
(https://bugzilla.mozilla.org/show_bug.cgi?id=669545) and
builders.addons.mozilla.org
(https://bugzilla.mozilla.org/show_bug.cgi?id=673304).
Nick
Wes Garland
This is *great*. One of the hardest problems I face these days is keeping
up with what's happening in the engine, I don't have time to lurk as much on
IRC this summer and reading bugs is very very tedious.
I appreciate this very much!
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Tom Schuster
Instead of just introduction new hires, it would be cool if we could
also get some new people who started working on the engine voluntarily
to introduce themselves.
I think this should be synced to planet.moz, i guess a lot of people
would be interested in this stuff, but don't really follow our
internal mailing list.
Getting recognition also makes you feel good :)
> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>
David Mandelin
> Awesome idea, loving it already.
>
> Instead of just introduction new hires, it would be cool if we could
> also get some new people who started working on the engine voluntarily
> to introduce themselves.
> I think this should be synced to planet.moz, i guess a lot of people
> would be interested in this stuff, but don't really follow our
> internal mailing list.
blog it will be on planet. The question is whether I should double-post,
post to my blog and link from the mailing list, or post only to the
blog. Double-posting kind of seems like the best option.
>
> Getting recognition also makes you feel good :)
Dave
Asa Dotzler
> Here's the first JS team update newsletter, as suggested by jorendorff.
> This first one covers roughly the previous 2 weeks. It seems pretty long
> so I'll try for a weekly update.
>
> If I missed any big news, please post it as a reply. Also, in the future
> feel free to email me about anything you'd like included in the next
> newsletter.
This is overflowing with WIN! Thank you!
Do you plan on doing these regularly on Thursdays or was Thursday just
the "when it happened to be ready" day? I ask because I don't follow
this group closely but I absolutely want to read this regularly.
Also, no rush and no pressure if you don't think it's important or a
good idea, but a companion blog would let people subscribe to just these
updates and not need to follow the full js-internals list to stay up to
date.
- A
David Mandelin
> David Mandelin wrote:
>> Here's the first JS team update newsletter, as suggested by jorendorff.
>> This first one covers roughly the previous 2 weeks. It seems pretty long
>> so I'll try for a weekly update.
>>
>> If I missed any big news, please post it as a reply. Also, in the future
>> feel free to email me about anything you'd like included in the next
>> newsletter.
>
>
> This is overflowing with WIN! Thank you!
>
> Do you plan on doing these regularly on Thursdays or was Thursday just
> the "when it happened to be ready" day? I ask because I don't follow
> this group closely but I absolutely want to read this regularly.
is now the default, unless someone has a good reason some other day is
better.
>
> Also, no rush and no pressure if you don't think it's important or a
> good idea, but a companion blog would let people subscribe to just
> these updates and not need to follow the full js-internals list to
> stay up to date.
should post it to my personal Mozilla blog, or create a new one just for
these updates?
Dave
Asa Dotzler
> On 7/29/2011 6:25 PM, Asa Dotzler wrote:
>> Do you plan on doing these regularly on Thursdays or was Thursday just
>> the "when it happened to be ready" day? I ask because I don't follow
>> this group closely but I absolutely want to read this regularly.
> It happened to be ready Thursday. I intend weekly updates, so Thursday
> is now the default, unless someone has a good reason some other day is
> better.
Any day is probably fine. I'm just interested in being able to pull in a
couple items to my Weekly Engineering Newsletter. On or before Wednesday
means I get to pull the freshest stuff. After Wednesday means that it
waits until my following update and by then it might be a little bit
stale. That's no big deal and certainly not worth you adjusting your
schedule. And any relatively fixed schedule is a win so I'm not gonna
complain.
>> Also, no rush and no pressure if you don't think it's important or a
>> good idea, but a companion blog would let people subscribe to just
>> these updates and not need to follow the full js-internals list to
>> stay up to date.
> Others have suggested it, and I think it's a good idea. Do you think I
> should post it to my personal Mozilla blog, or create a new one just for
> these updates?
I think it would be more consumable in its own feed. Either a category
or tag or something on your personal Mozilla blog or a standalone blog
would give us that. Then again, I'm not gonna complain if it's mixed in
with other Mozilla stuff at your blog. That it's happening is the clear
win and getting it into HTML however you do it is awesome.
- A