Compiler: add Task call, invoke, and fetch optimizations and operations by vtjnash · Pull Request #59221 · JuliaLang/julia

vtjnash · 2025-08-06T15:31:40Z

This commit implements a Task optimizations by adding a invoked field to the Task definition, which optionally causes it to do an invoke call internally instead of a regular call.

Key changes:

Add invoked field to Task structure, supporting Type, Method, MethodInstance, and CodeInstance, just like invoke
Implement _task builtin function to construct Task
Create PartialTask lattice element for precise task result and error type tracking
Unify several CallInfo types into IndirectCallInfo
Optimized calls to _task constructor to inject CodeInstance. Calling fully_covers isn't necessary, as the runtime will check that.

In the future we can consider making this field user-inaccessible (like scope) and then be able to optimize based on the type returned from fetch.

Also added documentation to base/docs/basedocs.jl on how to easily add more Builtin functions, following this as an example.

🤖 Generated with help from Claude Code

JeffBezanson · 2025-08-06T18:13:19Z

Compiler/src/stmtinfo.jl

+ - `modifyglobal!(mod, var, op, x, order)` where `op(getval(), x)` is called
+ - `memoryrefmodify!(memref, op, x, order, boundscheck)` where `op(getval(), x)` is called
+ - `Intrinsics.atomic_pointermodify(ptr, op, x, order)` where `op(getval(), x)` is called
+ - `Core._task(f, size)` where `f()` will be called when the task runs


Aren't task and finalizer different from the modify functions in that the modify functions eagerly call the argument at the call site, while task and finalizer are deferred? I thought that was important.

It isn't important. All that matters is that there is some separate broker function (e.g. like https://llvm.org/doxygen/classllvm_1_1AbstractCallSite.html)

JeffBezanson · 2025-08-06T19:24:02Z

stdlib/Serialization/src/Serialization.jl

        error("cannot serialize a running Task")
    end
+    if isdefined(t, :invoked)
+        error("cannot serialize a Task constructed with invoke info")


I'm not sure this is helpful, since if you hit this you can't really control it. We could just skip this field and hope it works out.

base/task.jl

src/builtins.c

JeffBezanson · 2025-08-06T19:28:02Z

Any benchmarks?

Compiler/src/abstractinterpretation.jl

aviatesk · 2025-08-06T19:43:19Z

Any benchmarks?

I was unable to confirm optimization results even in the simplest case on my end unfortunately.
Perhaps task construction/scheduling is becoming the bottleneck?

julia> func2(i) = fetch(Threads.@spawn sin(i));

julia> using BenchmarkTools

julia> @benchmark func2(42)

master:

BenchmarkTools.Trial: 10000 samples with 1 evaluation per sample.
 Range (min … max):  709.000 ns …  34.583 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):      12.667 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):    12.857 μs ± 976.688 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

                                            ▁▃▅▅█▇▄▄▅▄▃▂▁▁      ▂
  ▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▄████████████████▇▆▇ █
  709 ns        Histogram: log(frequency) by time       16.2 μs <

 Memory estimate: 352 bytes, allocs estimate: 6.

this PR:

BenchmarkTools.Trial: 10000 samples with 1 evaluation per sample.
 Range (min … max):  11.333 μs …  29.542 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     12.708 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):   12.602 μs ± 587.109 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

  ▄▆▃         ▁   ▁▄▅▆▅▄▃▄▇▇██▆▆▅▂▁▁▂ ▁▁▁   ▁                  ▃
  ███▇▇▆▆▇█▇▇▇█▇▇████████████████████████▇▇▇██▇▇▇█▆▅▆█▆▆▆▇▆▄▆▅ █
  11.3 μs       Histogram: log(frequency) by time      14.4 μs <

 Memory estimate: 352 bytes, allocs estimate: 6.

vtjnash · 2025-08-06T23:35:02Z

It was entirely process_events and scheduling issues for me, which are separately addressable. The main point is inference and trim, not performance at this time.

This commit implements a Task optimizations by adding a `invoked` field to the Task definition, which optionally causes it to do an `invoke` call internally instead of a regular `call`. Key changes: - Add `invoked` field to Task structure, supporting Type, Method, MethodInstance, and CodeInstance, just like invoke - Implement `_task` builtin function to construct Task - Create PartialTask lattice element for precise task result and error type tracking - Unify several CallInfo types into IndirectCallInfo - Optimized calls to `_task` constructor to inject CodeInstance. Calling `fully_covers` isn't necessary, as the runtime will check that. In the future we can make this field user-inaccessible (like scope) and then be able to optimize based on the type returned from `fetch`. Also added documentation to base/docs/basedocs.jl on how to easily add more Builtin functions, following this as an example. 🤖 Generated with help from [Claude Code](https://claude.ai/code)

Very similar to return_type. Because of the design of Task reusing the `result` field to mean a lot of different things, it is hard to make this inference safe and sound now. Try anyways to add a type-assert so that `fetch` is inferred even if the design of Task make it unsafe.

base/docs/basedocs.jl

doc/src/devdocs/builtins.md

Compiler/src/stmtinfo.jl

aviatesk · 2025-09-14T17:13:58Z

Compiler/test/effects.jl

+
+# task_result_type effects modeling (should have !consistent effect)
+let effects = Base.infer_effects(Core.task_result_type, (Task,))
+    @test !Compiler.is_consistent(effects)  # !consistent bit should be set


Is this because of Task's mutability? I know this has been talked about a lot already, but can't we make Task immutable in its semantics?

No, it is because inference becomes dangerously unsound if you accidentally ever infer the result of inference to be consistent

aviatesk · 2025-09-14T17:34:11Z

Rebased, added some higher-level tests with Threads.@spawn, and simplified the inlining.jl implementation a bit.

Co-authored-by: Shuhei Kadowaki <40514306+aviatesk@users.noreply.github.com>

aviatesk · 2025-09-19T09:36:35Z

Looks like now we are hitting this assertion:

Error in testset Serialization:
Error During Test at /cache/build/tester-amdci4-8/julialang/julia-master/julia-dfe6ed50b7/share/julia/test/testdefs.jl:25
  Got exception outside of a @test
  LoadError: cannot serialize a Task constructed with invoke info
  Stacktrace:
    [1] error(s::String)
      @ Base ./error.jl:44
    [2] serialize(s::Serializer{IOBuffer}, t::Task)
      @ Serialization /cache/build/tester-amdci4-8/julialang/julia-master/julia-dfe6ed50b7/share/julia/stdlib/v1.13/Serialization/src/Serialization.jl:502
    [3] serialize(s::IOBuffer, x::Task)
      @ Serialization /cache/build/tester-amdci4-8/julialang/julia-master/julia-dfe6ed50b7/share/julia/stdlib/v1.13/Serialization/src/Serialization.jl:818
    [4] (::Main.Test43Main_Serialization.var"#76#77")(s::IOBuffer)
      @ Main.Test43Main_Serialization /cache/build/tester-amdci4-8/julialang/julia-master/julia-dfe6ed50b7/share/julia/stdlib/v1.13/Serialization/test/runtests.jl:359
    [5] create_serialization_stream(f::Main.Test43Main_Serialization.var"#76#77")
      @ Main.Test43Main_Serialization /cache/build/tester-amdci4-8/julialang/julia-master/julia-dfe6ed50b7/share/julia/stdlib/v1.13/Serialization/test/runtests.jl:13
    [6] top-level scope
      @ /cache/build/tester-amdci4-8/julialang/julia-master/julia-dfe6ed50b7/share/julia/stdlib/v1.13/Serialization/test/runtests.jl:355
    [7] include(mod::Module, _path::String)
      @ Base ./Base.jl:308
    [8] macro expansion

vchuravy · 2026-02-02T13:41:08Z

Bump! There are some great improvements in here, would be good to merge.

vtjnash requested a review from aviatesk August 6, 2025 15:31

JeffBezanson reviewed Aug 6, 2025

View reviewed changes

base/task.jl Outdated Show resolved Hide resolved

JeffBezanson reviewed Aug 6, 2025

View reviewed changes

src/builtins.c Show resolved Hide resolved

aviatesk reviewed Aug 6, 2025

View reviewed changes

Compiler/src/abstractinterpretation.jl Outdated Show resolved Hide resolved

Compiler/src/abstractinterpretation.jl Outdated Show resolved Hide resolved

Compiler/src/abstractinterpretation.jl Outdated Show resolved Hide resolved

vtjnash force-pushed the jn/Task-fetch-inference branch from 6c17db1 to df3c99d Compare September 10, 2025 20:17

vtjnash requested a review from aviatesk September 10, 2025 20:17

vtjnash added the compiler:inference Type inference label Sep 10, 2025

vtjnash added 2 commits September 15, 2025 01:47

aviatesk reviewed Sep 14, 2025

View reviewed changes

aviatesk force-pushed the jn/Task-fetch-inference branch from df3c99d to c6a6187 Compare September 14, 2025 17:16

aviatesk added 2 commits September 15, 2025 02:20

add more high-level test with Threads.@spawn

95c7cf0

simplify inlining.jl

3e8b3da

vtjnash and others added 2 commits September 17, 2025 13:30

Apply suggestions from code review

f5cd633

Co-authored-by: Shuhei Kadowaki <40514306+aviatesk@users.noreply.github.com>

Apply suggestions from code review

dfe6ed5

aviatesk approved these changes Sep 18, 2025

View reviewed changes

vtjnash added the merge me PR is reviewed. Merge when all tests are passing label Sep 18, 2025

aviatesk removed the merge me PR is reviewed. Merge when all tests are passing label Sep 19, 2025

xal-0 mentioned this pull request Dec 1, 2025

Proactively compile lambdas when the type of the closure is known #60259

Merged

oscardssmith assigned vtjnash Feb 2, 2026

Uh oh!

Conversation

vtjnash commented Aug 6, 2025

Uh oh!

JeffBezanson Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

vtjnash Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

JeffBezanson Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

JeffBezanson commented Aug 6, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aviatesk commented Aug 6, 2025

Uh oh!

vtjnash commented Aug 6, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aviatesk Sep 14, 2025

Choose a reason for hiding this comment

Uh oh!

vtjnash Sep 17, 2025

Choose a reason for hiding this comment

Uh oh!

aviatesk commented Sep 14, 2025

Uh oh!

aviatesk commented Sep 19, 2025

Uh oh!

vchuravy commented Feb 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants