754664 - consider zero-cost exact stack rooting using the EH ABI

Status: RESOLVED WONTFIX

(Core :: JavaScript: GC, defect)

Description

[Luke Wagner [:luke]]

To implement zero-cost exception handling, C++ compilers have to build and have available at runtime a mapping from pc to an array of destructors to call if an exception is thrown at the pc.  To allow things like cross-module exceptions to work, this data has to be available through some ABI (linux/mac have http://sourcery.mentor.com/public/cxx-abi/abi-eh.html and x64 Windows has http://msdn.microsoft.com/en-us/library/7kcdt6fy%28VS.80%29.aspx).  Perhaps we could leverage/hack this to give us zero-cost exact GC rooting.  (In the absence of this info on x86 Windows or tier 2 platforms, we could use TLS to do a non-zero-cost strategy.)

So how exactly do we use the EH ABI?  One extremely rough idea is to do the following:
 1. build with exception handling turned on for libmozjs. (This slows down Windows x86, but shouldn't hurt x64 measurably: www.nwcpp.org/Downloads/2006/ehc.ppt.)
 2. give the root class a declared-but-not-defined destructor: this should generate an unresolved external symbol in the EH data
 3. as a post-compile build step, load up the binary, load up the EH info, find EH entries with the unresolved external symbol, replace the calls with magic asm sequences that encode the stack offset of the rooted pointer
 4. at runtime, on GC, walk the stack, use EH data to find roots.  (There may even be internal functions in the C++ runtime we could reuse for looking up the EH record.)

Benefits:
1. fastest GC roots in the west (question: how must faster?)
2. avoid the old SM game of trying to optimize usage/placement of roots (c.f. rootValue0).
3. remove that annoying 'cx' parameter to all roots
4. we could use exception handling!  Not everywhere, chaos-style, but incrementally, after subsets of the call graph have been audited.  This would avoid the terrible jit ballast hack, for one.  Overall, maybe 1/6th of SM is error handling that could be removed w/ EH.  

Does this sound at all sane?  It is the witching hour.

The big open question to me is what % of FF Windows users could run x64 builds. A related question is: how bad would the TLS-based-rooting + non-zero-cost-EH overhead be on x86 Windows.

Comment 1

[Luke Wagner [:luke]]

Thinking about this again (after sleep), we may not do enough rooting in C++ to justify all this.  (Perhaps some DOM binding paths would?)  I guess we could always estimate the effect by making rooting 2x slower and seeing if that affects anything.  If it doesn't, we might consider using TLS.

Comment 2

[Brian Hackett [Laid off!]]

(In reply to Luke Wagner [:luke] from comment #1)
> Thinking about this again (after sleep), we may not do enough rooting in C++
> to justify all this.  (Perhaps some DOM binding paths would?)  I guess we
> could always estimate the effect by making rooting 2x slower and seeing if
> that affects anything.  If it doesn't, we might consider using TLS.

My general feeling is that things which are hot enough in C++ should really be done in jitcode instead.  If this is a zero cost way to get fast rooters in, that would be great, but it doesn't sound like that is the case for Windows x86 (the most important platform for users) and it would be good to know what the overhead looks like there.

Comment 3

[Luke Wagner [:luke]]

(In reply to Brian Hackett (:bhackett) from comment #2)
> My general feeling is that things which are hot enough in C++ should really
> be done in jitcode instead.

Agreed

> but it doesn't sound like that is the case for
> Windows x86 (the most important platform for users)

Is it?  I'd like to know what % of users can't run 64-bit FF.