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

Dense :ka/:generic paths and the KA CPU backend allocate in the numeric phase (Julia 1.10, coverage)

Open
#53 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
julia

Research direction

Start with the T09 allocation test and test/utils.jl, then read src/numeric/factorize.jl and inspect the dense fallbacks in src/dense/fallback/. Compare :ka, :generic, and :auto allocation behavior across the stated Julia and coverage configurations. Done means the allocation contract and budget are consistently enforced, or the affected implementation scope is documented as suggested.

Written by the indexing model from the issue text.

Description

found-by-agent triaged

Found while working on: T09 (PR #52), review round 1

What: the T09 numeric phase (factorize!, src/numeric/factorize.jl) is allocation-free on the CPU backend only for impl = :auto on Julia ≥ 1.12 without coverage (64 B per call). Three allocation sources sit outside the T09 code proper:

  1. impl = :ka and impl = :generic allocate per front on CPU: the KA dense fallbacks of src/dense/fallback/ (T03) and the LinearAlgebra wrappers (cholesky! result objects, LowerTriangular/rdiv!) — about 33–39 KB (:ka) and 9–11 KB (:generic) per factorization of random_spd(300, 0.02) on Julia 1.12/1.13; 1.4–4.7 MB for :ka on Julia 1.10 under coverage.
  2. Julia 1.10 (the lts CI job): every KernelAbstractions CPU launch allocates 80–288 B (arguments boxed behind KA's __run inference barrier, KernelAbstractions/src/cpu.jl), i.e. ~9.6–11.5 KB per factorize! of that matrix with :auto. 0 B on 1.12 and 1.13. 1.11 not measured.
  3. With --code-coverage (CI's julia-runtest), the KA CPU backend heap-allocates @localmem MArrays: 2112 B per cholesky_stats! (@localmem Int64 (256,)), on every Julia version.

T09's allocation test now asserts ≤ 1024 + ka_cpu_alloc_budget(...) (test/utils.jl): strict 1024 B on Julia ≥ 1.12 without coverage, plus an explicit per-launch / localmem allowance for (2) and (3).

Why it is out of scope: (1) is T03 code (dense fallbacks); (2)/(3) are inside KernelAbstractions 0.9's CPU backend. None blocks T10/T11 on GPUs, but the PLAN §3.9 no-allocation contract (and later graph capture) only holds for :auto/:vendor, and CPU allocation tests in later tasks will need the same budget.

Suggested fix or plan change: give the :ka fallbacks preallocated workspaces/static launch configs and route :generic through allocation-free calls (or document :auto as the only allocation-free impl); reuse ka_cpu_alloc_budget in later allocation tests; drop items (2)/(3) when the package moves to KA 0.10.

Dominant language
Julia
Stars
3
Forks
0
Avg merge
3h 49m
Merged PRs (30d)
68

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

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 exanauts/SparseDirectSolver.jl

All issues in exanauts/SparseDirectSolver.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.