1394006 - Consider using direct jumps for Ion ICs

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine: JIT, enhancement, P3)

Description

[Brian Hackett [Laid off!]]

Attachment: patch

Ion ICs use indirect jumps through heap pointers to traverse the chain of stubs in the IC.  This is nice because patching and memory protection changes are not needed when changing the stub chain, but these indirect jumps are slow.  On the microbenchmark below I forced Ion to use ICs for property accesses.  The resulting time is 420ms, while with the attached patch to use direct jumps instead the time is 290ms.  (Normal Ion is 80ms.)

According to bug 1322093 comment 3 there are perf issues with mprotect when patching jumps instead of using indirect jumps.  I couldn't find the bug referred to there but I think it would be worth trying to address the perf issues resulting from this change directly (e.g. by batching repatching, as is done when poisoning dead JitCode, or by not discarding Ion stubs during GC) rather than living with this issue.

This is especially important for bug 1383358, where I'm trying to add an Ion compilation tier that uses ICs for all property accesses and type barriers.

function foo() {
    var arr = [];
    for (var i = 0; i < 1000; i++)
	arr.push({f:1});
    var ret = 0;
    for (var j = 0; j < 100000; j++) {
	for (var k = 0; k < 1000; k++)
	    ret += arr[k].f;
    }
    return ret;
}
foo();

Comment 1

[Jan de Mooij [:jandem]]

Comment on attachment 8901343 [details] [diff] [review]
patch

(In reply to Brian Hackett (:bhackett) from comment #0)
> This is especially important for bug 1383358, where I'm trying to add an Ion
> compilation tier that uses ICs for all property accesses and type barriers.

I'd like to wait for perf numbers from that first, but my gut feeling is that Ion ICs are not great for this because (1) the mprotect overhead and (2) Ion IC stubs don't share code so we'll generate a ton of IC/JIT code and this has both perf and memory overhead.

Before I did the CacheIR conversion, mprotect overhead from attaching IC stubs often showed up in profiles. When we switched to indirect jumps, it did not regress any benchmarks. Your micro-benchmark is a best-case for direct jumps because there's a single stub that's entered a gazillion times. On the web (or say Speedometer) it's much more common to have, say, 10000 ICs with 4 stubs each that are entered maybe 50 times on average.

How will bug 1383358 affect, say, speedometer/sunspider? How much extra Ion IC code will we generate?