614953 - Don't route infallibleVMCalls through JaegerStubVeneer.

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Jacob Bramley [:jbramley]]

JaegerStubVeneer allows stub calls to hijack the return path on ARM, so THROW can work. This is only necessary for fallibleVMCalls, so calls made through infallibleVMCall can call the stub directly.

Earlier in the year I recall estimating that the veneer imposed around a 4% performance penalty. We can't get all of that back because we can only skip it for infallible calls, but it's probably worth doing nonetheless.

Comment 1

[Jacob Bramley [:jbramley]]

Note that the complexity here is not in separating the calls, but in ensuring that infallibleVMCalls can be patched to point somewhere else. As it is, I think only fallibleVMCalls get patched, but it doesn't look obvious that we can rely on this distinction.

If both call styles need to be patchable, then the back-ends need to be able to patch two different call sequences. This is only a problem for ARM at the moment, as only ARM calls stubs through a veneer, though other architectures will most likely have to use a similar mechanism if they are added in the future.

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

Ideally this distinction shouldn't matter. Is it possible to fudge the Call label returned by calls, so that it repatches the right thing instead of the veneer?

Comment 3

[Jacob Bramley [:jbramley]]

(In reply to comment #2)
> Ideally this distinction shouldn't matter. Is it possible to fudge the Call
> label returned by calls, so that it repatches the right thing instead of the
> veneer?

The distinction matters because a call through the veneer is more
expensive than a direct call. We should be able to fudge the call label.

If we call through a veneer, we emit this:

  ldr  ip, =target
  ldr  r8, =JaegerStubVeneer
  blx  r8

If we call directly, we emit this:

  ldr  r8, =target
  blx  r8

Currently, we always call stubs through the veneer, but we don't have to
do that for infallible calls. I discussed this with Chris yesterday, and
I think we can modify OOL_STUBCALL so that we can hide this from the
rest of JM. We can also do away with the 'relinkStubCall' method that I
put into the repatcher (in our PIC MQ).

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

I mean, it makes sense to emit it in one path and not another, but why does that affect its repachability?

Comment 5

[Jacob Bramley [:jbramley]]

Oh, it doesn't. I thought that it had some assertions to check for an expected code sequence, but when Chris and I looked through the code yesterday, we discovered that it will actually just work, so the only required change is on OOL_STUBCALL.

Comment 6

[David Anderson [:dvander] - inactive, e-mail if emergency]

INLINE_STUBCALL is fallible too, though - do you mean fallibleVMCall? Hiding the details in BaseAssembler seems ideal, in case ICs ever want to generate fallible calls.

Comment 7

[Jacob Bramley [:jbramley]]

Oh, yeah. I haven't actually looked at the implementations of the _STUBCALL functions. INLINE_STUBCALL would need to be covered too, so fallibleVMCall might be the place to put it. I really just meant that Compiler.cpp and (Poly|Mono)IC.cpp won't have to handle any new methods.

Comment 8

[Jan de Mooij [:jandem]]

JM is gone.