I like the idea. I don't feel like it's something that the compiler needs to do automatically, in general, keeping this and parameters live is just how things work by default, and Scala / Java programmers are used to it. So an annotation seems like a good way to give people the option when they need it.

Some ideas

• it should also work for other parameters than this
• maybe we can annotate the method instead of the expression, and have the compiler figure out where to null out

• Detect aliasing of this into a var and reuse slot 0

Not sure we need to do that, see also my comment below. The inliner nulls out local variables (e.g. the one holding this) of inlined code, but it doesn't make any attempts to re-use slots.

• Share other LVT slots between non-overlapping variables of compatible types

We never went to implement a register allocator in the Scala backend because (1) the JVM does it and (2) having a slot per local variable makes other local analyses / optimziations much simpler. Also, I'm not sure if it would be a good idea to rely on register allocation for "correctness" (i.e., to rely on the register allocator to null out this in time).

Side-note: "compatible types" is not a necessary requirement, a local variable slot can hold objects of different types (even reference / primitive) within the same method.

I don't feel like it's something that the compiler needs to do automatically, in general, keeping this and parameters live is just how things work by default, and Scala / Java programmers are used to it

It doesn't need to (especially if you have an annotation to trigger it on demand) but it would be nice to do it automatically when it's free (i.e. you don't need a null assignment). I haven't done any benchmarking specifically for this case yet but in several cases of benchmarking collection methods I noticed that tail-recursive versions were faster than iterative versions. I suspect it is precicely because of this difference (the iterative version has to keep an extra variable around). Note that you cannot rely on the VM to not drop the reference anyway (see https://shipilev.net/jvm/anatomy-quarks/8-local-var-reachability/).

it should also work for other parameters than this

Right. In fact, it should also work for all local variables. Are there any cases where the code generator creates new local variables for sub-expressions that could accidentally keep a reference alive? If this is the case, we may want to allow it for arbitrary expressions.

maybe we can annotate the method instead of the expression, and have the compiler figure out where to null out

That was my original plan but it's useless for ensuring that your methods actually drops the reference when you intend to. this always becomes unreachable at some point but you want an assurance that it becomes unreachable early enough (before you start looping). The result is similar to how @tailrec ensures that all self-recursive calls are in tail position and can be optimized.

Also, I'm not sure if it would be a good idea to rely on register allocation for "correctness" (i.e., to rely on the register allocator to null out this in time)

Right, this would just be a general optimization. If you want to be sure you still need to annotate it (similar to how @tailrec is not required for the optimization but will ensure that it can be performed).

Side-note: "compatible types" is not a necessary requirement, a local variable slot can hold objects of different types (even reference / primitive) within the same method.

Good point. I didn't consider this for this and parameters. This means we could drop this automatically (without the need for an annotation) in even more cases. Ideally, I'd like the annotation to only perform the checks and have the optimization applied automatically in all cases (like @tailrec) but there are still some cases left where explicit nulling is required.

Are there any cases where the code generator creates new local variables for sub-expressions that could accidentally keep a reference alive?

That's a good question, I'd have to look in detail, but I can imagine this being the case. For example to emit try-catch expressions.

Note to self (or anyone else who might already know the answer): After looking at the LazyList PR again, it's clear that simple forwarders (like LazyList#collect) do not pose a problem. References to this are dropped even though they are (or at least should be) in the LVT. Why does this work? Can we rely on the JVM to drop references in case of tail calls or is there some other mechanism at work here?

After working on scala/bug#11443, it has become less clear. Using a @tailrec final def find in Stream is fine, but putting the code into a separate findImpl method with find acting as a forwarder (to allow moving the implementation up into LinearSeqOps) does not allow the original receiver to be garbage collected.

@szeiger should we close this one?

I don't think I'll be able to continue with this any time soon

This PR would enable heap safe implementations without relying on

• either @tailrec (which re-assigns this / slot 0)
• or the JVM JIT (which seems to compile / optimize code such that the this reference can be collected early, possibly due to register allocation, as hinted by the shipilev post linked above).

Difficulties

• inherited final methods, e.g., mkString (inherited from IterableOnceOps), cannot override to use @nullOut
• final forwarders like IterableOnceOps./: - even if foldLeft is heap safe (it currently is), using /: leaves the this reference live in the stack frame of the /: method
• Synthetic forwarders (bridges, mixin forwarders, static mixin accessors, super accessors?)
• Sometimes there's nothing to override in the lazy collection, like Growable.addAll(elems: IterableOnce[A]). We'd have to use @nullOut in the generic implementation. In the concrete example, we'd have to write:

trait Growable {
  final def ++=(elems: IterableOnce[A]): this.type = this.addAll(elems: @nullOut)

  def addAll(elems: IterableOnce[A]): this.type = {
    val it = (elems: @nullOut).iterator
    while (it.hasNext) {
      addOne(it.next())
    }
    this
  }
}

/: and mkString could be fixed in the same way. I'm not sure that is a worthwhile tradeoff to have these annotations around the library implementation and not contained within LazyList / Stream.

On the other hand, we could fix heap safety and even get rid of current overrides in LazyList with a few null assignments which won't hurt performance.

it should also work for all local variables

I was going to argue that we can use vars and null them out manually, but for something like localLazyList.reduceLeft we cannot express "load localLazyList onto the stack and null it out, then call reduceLeft".

If you use it and try to dereference this afterwards, you get an NPE. The next obvious step is to add these checks.

IMO we can do without, especially if this is going to be an internal feature. The compiler also doesn't check how local variables are used after setting them to null.

Scala 3 explicit nulls has the necessary flow typing, but it would need to be tweaked to understand the annotation.