Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

signature_type_by_tt allocates on every launch on Julia 1.14

Open
  • Is something wrong?
#1,024 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@maleadt is already working on this.

Since Oct 17, 2026.

  • #1025 by @maleadt — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
julia
Domain
backend, performance

Research direction

Start in the signature_type_by_tt implementation and compare its Julia 1.14 path with the pre-1.14 tuple splatting path. The reproducer in the issue measures allocations for sig_splat and sig_map; use it to verify the allocation difference and check behavior when dispatch_key changes type parameters. Done means avoiding the reported per-lookup allocations while preserving the needed dispatch behavior; pull request #1025 is already open.

Written by the indexing model from the issue text.

Description

On Julia 1.14 (where Core.TypeEgal is defined), signature_type_by_tt builds the signature with map(dispatch_key, u.parameters):

@inline function signature_type_by_tt(ft::Type, tt::Type)
    u = Base.unwrap_unionall(tt)::DataType
    return Base.rewrap_unionall(Tuple{dispatch_key(ft), map(dispatch_key, u.parameters)...}, tt)
end

Unlike Tuple{ft, u.parameters...}, which the pre-1.14 branch uses and which is folded to a constant for a constant tt, map over the SimpleVector isn't folded: it allocates a Vector{Any} and constructs the tuple type at run time. Since methodinstance calls this on every lookup, every kernel launch through a cached cufunction/clfunction/... allocates, proportionally to the number of arguments.

This shows up in KernelAbstractions' POCL back-end, where a launch with 4 scalar arguments allocates 128 bytes more than on Julia 1.13 and one with 40 arguments 416 bytes more (Profile.Allocs: Memory{Any}, Vector{Any} and a CorruptType from signature_type_by_tt < methodinstance < clfunction), failing KA's "POCL launch with many arguments" test on nightly.

Reproducer without GPUCompiler (same results on 1.13 and 1.14.0-DEV):

@inline function dispatch_key(@nospecialize(t))
    if Base.isType(t)
        u = Base.type_parameter(t)
        !Base.has_free_typevars(u) && return isdefined(Core, :TypeEgal) ? Core.TypeEgal{u} : Type{u}
    end
    return t
end
@inline sig_splat(ft::Type, tt::Type) = Tuple{ft, (tt::DataType).parameters...}
@inline sig_map(ft::Type, tt::Type) = Tuple{dispatch_key(ft), map(dispatch_key, (tt::DataType).parameters)...}

kern(args...) = nothing
const TT = Tuple{Vector{Int}, ntuple(_ -> Int, 40)...}
f_splat() = sig_splat(typeof(kern), TT)
f_map() = sig_map(typeof(kern), TT)
f_splat(); f_map()
@show @allocated(f_splat())   # 0
@show @allocated(f_map())     # 432

Taking the splatting path unless ft or one of the parameters is a Type{...} (the only case where dispatch_key changes anything) avoids the allocations.

Dominant language
Julia
Stars
188
Forks
71
Avg merge
1d 17h
Merged PRs (30d)
60

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from JuliaGPU/GPUCompiler.jl

All issues in JuliaGPU/GPUCompiler.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.