Weird finalizer bug: finalize() does not execute installed finalizer function sometimes

[amitmurthy]

Ran into this while working on DistributedArrays. A somewhat reduced test case is described here:

addprocs(1)

callme(f) = @schedule println("CALLED!")

type Foo{T,N} <: AbstractArray{T, N}
    a::RemoteRef
    Foo(n) = (f=new(remotecall(ones, 2, n)); finalizer(f, callme); f)
end

Base.getindex(d::Foo, i::Int) = d.a[i]
Base.getindex(d::Foo, i::Int...) = d.a[i...]
Base.getindex(d::Foo) = d[1]

Base.size(d::Foo) = size(fetch(d.a))

f1 = Foo{Float64, 2}((55, 55));

f1 == f1

finalize(f1)

The finalizer on Foo is NOT called if the equality test f1==f1 is performed on Foo sizes greater than (54,54)

Examples:

Called with equality test and sizes (54, 54) and (54, 55).
(54,55) is not predictable - sometimes it is called and sometimes not.

julia> f1 = Foo{Float64, 2}((54, 54));

julia> f1 == f1
true

julia> finalize(f1)
CALLED!


julia> f1 = Foo{Float64, 2}((54, 55));

julia> f1 == f1
true

julia> finalize(f1)
CALLED!

NOT called with equality test and size (55,55)

julia> f1 = Foo{Float64, 2}((55, 55));

julia> f1 == f1
true

julia> finalize(f1)

Called with equality test commented out.

julia> f1 = Foo{Float64, 2}((55, 55));

julia> #f1 == f1
       finalize(f1)
CALLED!

[ViralBShah]

Cc @carnaval

[yuyichao]

The reason is that the finalizer is moved to the list for the old objects and we were not checking that list for finalizers when you explicitly call the finalize...... The "weird" effect you are seeing is basically promotion to the old gen...

Fixed in #13988