647991 - TI+JM: Assertion failure: Call site vanished., at ../methodjit/Retcon.cpp:112

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

[""][NaN] = 2;
-([][[""][String] = ""] = null);

This obscure snippet fails with -m -n -a at revision 7928f2dc3d4d:

$ ./js -m -n -a test.js
Assertion failure: Call site vanished., at ../methodjit/Retcon.cpp:112

Comment 1

[Brian Hackett [Laid off!]]

The first times we go through the SETELEM assigning null, we go through an inline stub call and forget the SETELEM is pushing a constant 'null'.  Then when recompiling from the Neg we make the SETELEM stub call OOL and get the constant pushed value which we fold in the Neg.

This could be fixed by remembering the constant across the inline stub call, but I think it's easier and simpler to bite the bullet and allow all constants and copies to be unstable across compilations.  This would free the compiler to make any decision it wants wrt pushing constants and syncing based on the input types, and would require us to emit OOL rejoin paths when folding constants (not a big deal).  (additionally, I don't think the pushed singletons are stable across compilations, we just haven't found a fuzz test exposing the problem).

Will fix.

Comment 2

[Jan de Mooij [:jandem]]

Attachment: Another testcase

Here's another test case. It fails to rejoin after a recompilation triggered by Math.floor(-0).

Comment 3

[Brian Hackett [Laid off!]]

This splits things out so that we don't rejoin at arbitrary call sites but at rejoin sites that have been added to the code, adjust var/stack double types as necessary and jump to the right place.  Normal use is with the REJOIN_SITE or REJOIN_SITE_ANY macros, which define structures that generate the rejoin sites when they are destroyed --- after the fast/stub paths for the op have been generated, and regardless of the path taken through the op.

http://hg.mozilla.org/projects/jaegermonkey/rev/3816e4abb158