Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Julia 1.9.0 freezes in subtyping #49857

Closed
kpamnany opened this issue May 17, 2023 · 4 comments
Closed

Julia 1.9.0 freezes in subtyping #49857

kpamnany opened this issue May 17, 2023 · 4 comments
Assignees

Comments

@kpamnany
Copy link
Contributor

kpamnany commented May 17, 2023

julia> versioninfo()
Julia Version 1.9.0
Commit 8e630552924 (2023-05-07 11:25 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 12 × Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-14.0.6 (ORCJIT, skylake)
  Threads: 1 on 12 virtual cores

Reproducer:

julia> x = Tuple{Type{Array{Union{Nothing, Bool, Char, Float16, Float32, Float64, Int128, Int16, Int32, Int64, Int8, UInt128, UInt16, UInt32, UInt64, UInt8, Missing, Base.Regex, String, Symbol, Tuple, Base.Rational{T} where T<:Integer}, 1}}, UndefInitializer, Tuple{Int64}}
Tuple{Type{Vector{Union{Missing, Nothing, Bool, Char, Float16, Float32, Float64, Int128, Int16, Int32, Int64, Int8, UInt128, UInt16, UInt32, UInt64, UInt8, Regex, String, Symbol, Tuple, Rational}}}, UndefInitializer, Tuple{Int64}}

julia> y = Tuple{Type{Array{T, N} where N}, UndefInitializer, Tuple{Vararg{Integer, N}}} where N where T
Tuple{Type{Array{T}}, UndefInitializer, Tuple{Vararg{Integer, N}}} where {T, N}

julia> x <: y  # freezes

This worked on 1.8 and is also fixed on master.

@kpamnany
Copy link
Contributor Author

@quinnj bisected this and found the commit that introduces the freeze.

Subsequently, this commit fixes the freeze.

Unfortunately, there are manymany commits in between. It seems intractable to backport all of them.

@quinnj
Copy link
Member

quinnj commented May 17, 2023

I think my question is where to go from here; the options seem to be 1) try to backport a good chunk of the subtyping changes or 2) revert the 1 commit from 1.9. The tricky part is that the commit that caused the perf regression also fixed #40865, so I guess another question is what do we think is more common/problematic: the original #40865 issue? Or people running into the perf regression we're seeing here?

Maybe @vtjnash has a sense for the best path forward here?

@kpamnany
Copy link
Contributor Author

Related: #49323 and #48582

@N5N3 N5N3 self-assigned this May 18, 2023
N5N3 added a commit to N5N3/julia that referenced this issue May 18, 2023
The union explosion is caused by the following MWE:
Type{Vector{Union{....}} <: Type{Array{T}} where {T}

280f999 only fixes for `Union{......}` without free `Typevar`. This fast-path makes sure the remaining get fixed.

This fast-path fixes the remaining issue with the same pattern.
N5N3 added a commit to N5N3/julia that referenced this issue May 18, 2023
The union explosion is caused by the following MWE:
Type{Vector{Union{....}} <: Type{Array{T}} where {T}

280f999 only fixes for `Union{......}` without free `Typevar`. This fast-path makes sure the remaining get fixed.
@kpamnany
Copy link
Contributor Author

This is fixed for 1.9.1 by #49875.

vtjnash pushed a commit that referenced this issue May 20, 2023
For #49857 performance

The union explosion is caused by the following MWE:
`Type{Vector{Union{....}} <: Type{Array{T}} where {T}`

280f999 only fixes for `Union{......}`
without free `Typevar`. This fast-path makes sure the remaining get fixed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants