cmd/compile: closures in generic functions capture type dictionaries unconditionally

[mcy]

Consider the following program:

package p

func f[T any]() func() {
    return func() {}
}

func g() func() {
    return func() {}
}

var x = f[int]
var y = g

One expects f and g to be identical, because they have identical bodies. However, because f is generic, the type dictionary for its type arguments is captured, meaning that f's closure escapes to the heap.

        TEXT    .g(SB)
        LEAQ    .g.func1·f(SB), AX
        RET

        TEXT    .f[int](SB)
        PUSHQ   BP
        MOVQ    SP, BP
        SUBQ    $16, SP
        NOP
        LEAQ    type:noalg.struct { F uintptr; X0 *[0]uintptr }(SB), AX
        CALL    runtime.newobject(SB)
        LEAQ    .f[int].f[go.shape.int].func1(SB), CX
        MOVQ    CX, (AX)
        LEAQ    ..dict.f[int](SB), CX
        MOVQ    CX, 8(AX)
        ADDQ    $16, SP
        POPQ    BP
        RET

[gabyhelp]

Related Issues

• cmd/compile: bad handling of closures in generic body #45738 (closed)
• cmd/compile: internal compiler error: dictionary variable not captured by value #52907 (closed)
• cmd/compile: generic method values at package scope pin their receiver value #54343 (closed)
• cmd/compile: generic function argument causes escape to heap #48849

Related Code Changes

• [dev.typeparams] cmd/compile: add derived types and subdictionaries to dictionaries
• cmd/compile: keep methods on generic types from being deadcode eliminated
• [dev.typeparams] cmd/compile: add derived types and subdictionaries to dictionaries
• cmd/compile: add dictionary argument to generic functions
• [dev.typeparams] cmd/compile: start using sub-dictionary entries where needed

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mwriter]

However, because f is generic, the type dictionary for its type arguments is captured, meaning that f's closure escapes to the heap.

And is it possible to avoid this without monomorphization?
In Golang, after all, only dynamic dispatching is implemented when working with generics.
But it seems to me that in your particular example, the main problem is the incorrect implementation logic.

[mcy]

@mwriter if nothing in the body depends on the type dictionary, yes. This is true if the body does not reference the type parameter(s), or only uses them in a way that that depends only on information known to a particular GC shape stencil. The following operations do not depend on the dictionary: the layout of type parameters, arithmetic (except shifts), pointer conversions, all slice operations except make, and non-generic function calls (and a few others I'm forgetting).

[mwriter]

if nothing in the body depends on the type dictionary, yes

This will require additional static analysis. And here you need to take into account that Go team is trying to make the build as fast as possible, and transfer overhead costs already in runtime. And although I think it's wrong to dictate only one approach, and it's better to offer several approaches as in Rust, you probably still have to prove to the team that this additional waste of time on such an analysis will always be minimal and appropriate.

This is true if

It just seems to me that you're suggesting encouraging bad code to be written. Can you give me an example of good code where it would be important?

[randall77]

I think this is a reasonable request. For instance, any closure you pass to slices.SortFunc from within generic code will capture, when it might not have needed to otherwise.

func f[T any](x []T) {
    a := make([]int, len(x))
    // Fill in a, using x somehow (maybe instead of `any`, the constraint is something that has a priority method).
    slices.SortFunc(a, func(x, y int) int { return x - y }) // this closure captures the dictionary, but doesn't need to
}

That said, I'm not sure that this issue is particularly high priority.
In my case I think the closure is stack allocated, so it isn't a big deal that it captures the dictionary.

[mwriter]

For instance, any closure you pass to slices.SortFunc from within generic code will capture, when it might not have needed to otherwise.

Now I see, thanks for the example.

[mwriter]

@randall77

On the other hand, though:

func f[T any](x []T) {
    slices.SortFunc(make([]int, len(x)), intSort)
}

func intSort(x, y int) int { return x - y }

There won't be any problems with this code, will there?

[randall77]

There won't be any problems with this code, will there?

Correct.

[mwriter]

Correct.

Then, again, could the problem be caused by insufficiently good code?
Maybe I'm stupid, but so far I can't think of a really good example that couldn't be improved.

[mcy]

@mwriter consider the following program:

type s struct {
  data unsafe.Pointer
  len int
  delete func(s, int) s
}

func new[T any](x []T) s {
  return s{
    data: unsafe.Pointer(unsafe.SliceData(x)),
    len: len(x),
    delete: func(s s, n int) s {
      buf := unsafe.Slice((*T)(s.data), s.len)
      copy(buf[n:], buf[n+1:])
      s.len = len(buf)-1
      return s
    }
  }
}

func (s *s) delete(n int) {
  s = s.delete(s, n)
}

Notice carefully that new[int] does not need to allocate, because copy on noscan types directly calls runtime.memmove, so the type dictionary is not needed. This is unfortunately a common problem when creating vtables of this nature, something that happens a lot in high-performance code (interfaces break escape analysis and can trigger redundant allocations).

Separately -- and this is just my opinion as a professional compiler writer -- I do not concern myself in the quality of users' code when designing or advocating for optimizations. Suboptimal code like this can be generated by compiler passes or (as is unfortunately popular in pre-generics Go) source code generation. It's very important to spot weird corner cases like this, because they are often clues for easy gains in unexpected places.

[mwriter]

I do not concern myself in the quality of users' code when designing or advocating for optimizations.

I understand your opinion. I can't say that I completely agree with him. But since I sometimes use such things myself, I understand your interest.
I hope you get lucky :)