fix ordering dependence of method cache insertion #16084

vtjnash · 2016-04-27T20:34:51Z

previously, a cache entry would be widened beyond the
despecialization heuristic, creating an ordering dependence
such that after inserting a Function into the cache (as Any)
or a Tuple (as DataType), no more methods would attempt to specialize
that slot

@JeffBezanson I think this should fix the issue you noted #15934 (comment)

In particular, given the command sequence:

f(x) = x
f(+)
f(-)
f(2)

before:

julia> typeof(f).name.mt.cache
f(x) at REPL[1]:1

julia> typeof(f).name.mt.cache.next
nothing

after:

julia> typeof(f).name.mt.cache
f(x::Int64) at REPL[1]:1

julia> typeof(f).name.mt.cache.next
f(x::Function) at REPL[1]:1

julia> typeof(f).name.mt.cache.next.next
nothing

JeffBezanson · 2016-04-27T20:55:22Z

Excellent. Were you able to reproduce the test slowdown?

vtjnash · 2016-04-27T21:02:33Z

No, I was just hoping you would be able to test this somehow :). I had recalled that I had noticed this ordering issue in the past, but had forgotten again and previously not been able to address it.

JeffBezanson · 2016-04-27T21:16:27Z

src/gf.c

@@ -609,6 +615,19 @@ static jl_lambda_info_t *cache_method(jl_methtable_t *mt, union jl_typemap_t *ca
        // in the method cache to prevent anything else from matching this entry
        origtype = NULL;
    }
+    if (makesimplesig && origtype == NULL) {
+        // reduce the complexity of rejecting this entry in the cache


I'm having trouble visualizing when this case happens. Could you give an example?

See the example in the PR. This lets us make an expensive cache entry like (<: Function), while still using the fast-path to reject it (although the (<: Any) it builds isn't a particularly useful example since it only has one argument)

I tried that but I always saw ::Function entries in the cache. I didn't the effect of this replacement with ::Any.

this ends up in the simplified-signature field. the primary sig field still gets ::Function (which is also what we bother to print)

previously, a cache entry would be widened beyond the despecialization heuristic, creating an ordering dependence such that after inserting a Function into the cache (as Any) or a Tuple (as DataType), no more methods would attempt to specialize that slot should fix the issue noted #15934 (comment)

tkelman · 2016-04-28T05:16:04Z

src/jltypes.c

@@ -3702,6 +3703,12 @@ void jl_init_types(void)
    slot_sym = jl_symbol("slot");
    static_parameter_sym = jl_symbol("static_parameter");
    compiler_temp_sym = jl_symbol("#temp#");
+
+    tttvar = jl_new_typevar(jl_symbol("T"),
+                                  (jl_value_t*)jl_bottom_type,


funny indent?

JeffBezanson reviewed Apr 27, 2016
View reviewed changes

vtjnash force-pushed the jn/cache-predictable branch from ad49a77 to 5c66898 Compare April 28, 2016 02:46

tkelman reviewed Apr 28, 2016
View reviewed changes

vtjnash merged commit 83b2fa4 into master Apr 29, 2016

vtjnash deleted the jn/cache-predictable branch April 29, 2016 19:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix ordering dependence of method cache insertion #16084

fix ordering dependence of method cache insertion #16084

vtjnash commented Apr 27, 2016

JeffBezanson commented Apr 27, 2016

vtjnash commented Apr 27, 2016

JeffBezanson Apr 27, 2016

vtjnash Apr 27, 2016

JeffBezanson Apr 28, 2016

vtjnash Apr 28, 2016

tkelman Apr 28, 2016

fix ordering dependence of method cache insertion #16084

fix ordering dependence of method cache insertion #16084

Conversation

vtjnash commented Apr 27, 2016

JeffBezanson commented Apr 27, 2016

vtjnash commented Apr 27, 2016

JeffBezanson Apr 27, 2016

Choose a reason for hiding this comment

vtjnash Apr 27, 2016

Choose a reason for hiding this comment

JeffBezanson Apr 28, 2016

Choose a reason for hiding this comment

vtjnash Apr 28, 2016

Choose a reason for hiding this comment

tkelman Apr 28, 2016

Choose a reason for hiding this comment