1913924 - Experiment with removing VMFunction wrappers

Status: ASSIGNED

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

Description

[Jan de Mooij [:jandem]]

Last week Ted and I came up with some ideas for 'inlining' VMFunction wrappers by emitting the equivalent code directly at the call site.

The main benefit of this is faster JIT => C++ calls by reducing the number of memory loads/stores for the arguments. It would also avoid some frame pointer overhead. Especially for Baseline Interpreter/IC code that's shared, we don't gain much by calling out to separate trampoline code.

The first step here is to identify some hot VM functions and then prototype calling these functions directly and measure how this affects performance and code size.

Comment 1

[Iain Ireland [:iain]]

We do a lot of VM calls. Even if this is a relatively small performance win per-call, it seems quite plausible that it's a meaningful improvement overall.

js-perf-next: Evaluate the performance/code-size implications of doing this by hand for a few hot functions, then implement it if the numbers look good.

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Nicolas: What's your update here?

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #2)

Nicolas: What's your update here?

Still on my list, I just have been pulled away by some crazyness is better left untold for everybody's sanity.

So far the approach I planned so far was to:

• Add arguments to a new callVM functions, similar to oolCallVM.
• Add a new callVM functions which merges the implementation of the original callVM with the implementation of the VM wrapper.
• Check performance and remove VM wrapper if beneficial.

Comment 4

[Iain Ireland [:iain]]

One additional step that might be worthwhile would be to pick a single hot VM call (there are lists Jan produced of the hottest VM calls in JS3/SP3 in bug 1935626), rewrite it completely by hand for a single platform (using base masm), and then profile ro measure how much improvement we would expect. It's a little bit of extra work up front, but it might save some time if it turns out this isn't a big overhead after all.

Depends on how quickly you think you can write a VM call by hand, I guess.

Comment 5

[Jan de Mooij [:jandem]]

I just realized that this also lets us use setupAlignedABICall from Ion code instead of the current setupUnalignedABICall from the VM wrapper.

When we converted all callWithABIs in Ion to setupAlignedABICall it was a measurable speedup (bug 1763592).

Comment 6

[Nicolas B. Pierron [:nbp]]

(In reply to Jan de Mooij [:jandem] from comment #5)

I just realized that this also lets us use setupAlignedABICall from Ion code instead of the current setupUnalignedABICall from the VM wrapper.

I experimented with this a bit, but we would have to fix the following first:

• The tail-call register handling, which offsets the framePushed accounting to avoid assertions when pulling the return address out of the stack.
• The offset at which IC are called. At the moment IC are entered with no strict stack depth alignment.

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Nicolas B. Pierron [:nbp] from comment #6)

I experimented with this a bit, but we would have to fix the following first:

• The tail-call register handling, which offsets the framePushed accounting to avoid assertions when pulling the return address out of the stack.
• The offset at which IC are called. At the moment IC are entered with no strict stack depth alignment.

These issues don't affect calls coming from Ion's CodeGenerator where we always have a known stack alignment, right? I was suggesting using setupAlignedABICall only for that case, not for VM calls from Baseline or IC code.

Comment 8

[Matthew Gaudet (he/him) [:mgaudet]]

Nicolas: What's the current state of this? If someone else was to look at this, what would you share?

Comment 9

[Nicolas B. Pierron [:nbp]]

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #8)

Nicolas: What's the current state of this? If someone else was to look at this, what would you share?

I am tiding up the patches and fixing other platform issues.