637856 - TypeInference: tracer integration

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

Currently, enabling type inference disables the tracer.  Fixing this should not be hard, the main problem is making sure that any code which is traced has been analyzed by inference, and that unexpected dynamic behavior (integer overflows, accessing missing properties) gets reported properly.

This is separate from the issue of having the tracer actually use inference results (which requires a mechanism to discard traces after type information has changed).

Comment 1

[Shu-yu Guo [:shu]]

Attachment: Tracer feedback to inference

Imacros don't correctly propagate information back to inference. This patch attempts to fix the types after the imacro has finished executing.

Comment 2

[Shu-yu Guo [:shu]]

The tracer never runs without having gone through the interpreter at least once during recording, so during that phase inference is ensured to run.

Currently the tracer has side exits on specialized types already, and when it bails out it *re-executes* the bytecode that caused the guard to fail. This re-execution should propagate correct type information.

The question is: are there cases where the tracer does not bail out on its type assumptions but there are still inference-observable changes to existing types?

I can't find any, but maybe bhackett can weigh in on this.

Comment 3

[Shu-yu Guo [:shu]]

Attachment: Tracer feedback, fixes NEW{INIT,OBJECT}

Fixes incorrect emitted code from the recorder for |JSOP_NEWINIT| and |JSOP_NEWOBJECT|

Comment 4

[Brian Hackett [Laid off!]]

(In reply to comment #2)
> The tracer never runs without having gone through the interpreter at least
> once during recording, so during that phase inference is ensured to run.
> 
> Currently the tracer has side exits on specialized types already, and when
> it bails out it *re-executes* the bytecode that caused the guard to fail.
> This re-execution should propagate correct type information.
> 
> The question is: are there cases where the tracer does not bail out on its
> type assumptions but there are still inference-observable changes to
> existing types?
> 
> I can't find any, but maybe bhackett can weigh in on this.

I don't think there will be much to worry about here, most of the side exits the tracer takes are testing information we know about statically, and the additional dynamic type results (like integer overflow) should throw things off trace already.  Type barriers need to be tested when in place, which will introduce new side exits but should be OK if the op was side effect free.  Also, type changes will be able to throw things off trace at different points in the VM than was possible previously, I don't know if this will cause problems.

Comment 5

[Shu-yu Guo [:shu]]

Attachment: Tracer feedback, fixes NEW{INIT,OBJECT}

Updated against new TM merge in JM

Comment 6

[Shu-yu Guo [:shu]]

Attachment: imacros and NEW{INIT,OBJECT} fixes

Comment 7

[Shu-yu Guo [:shu]]

Attachment: Packed dense array fixes

Comment 8

[Shu-yu Guo [:shu]]

Attachment: Null closure creation fix

Comment 9

[Shu-yu Guo [:shu]]

Attachment: Unsigned right shift overflow fix

Comment 10

[Shu-yu Guo [:shu]]

Still a bunch more failures to go -- perhaps this bug should be split?

Comment 11

[Shu-yu Guo [:shu]]

Attachment: v1 wip

This patch makes all jit-tests pass with -n -a -j on JM:74432. It also includes a patch to not capture types of dead slots.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Is this WONTFIX now?

Comment 13

[Shu-yu Guo [:shu]]

I believe so -- the tracer should be slated for removal.