@gzm0 This is based on my experiments with trying to optimize the Wasm output. For everything else, I managed to make the Wasm output on average faster than Scala.js without touching the IR, or only in a way that also benefits JS (see #4998). For Scala functions, however, they remained desperately slow no matter what I tried. With these changes to the IR, overall Wasm reaches 0.85% the geomean run time wrt. JS -- so, 15% faster on average.

When you get the chance, I'd like your broad opinion on this. Is this something we could commit to at this stage? Or should we only venture this far if and when Wasm gets more mature/battle-tested? There's obviously a catch-22 here: given the performance results, Scala.js-on-Wasm might not be production-viable without this change; but without production experience we might not implement it. That doesn't mean we couldn't wait at least a full release cycle and reports of Wasm being correct, even if it is slow.

I have been thinking about this, and I think what is happening is actually the other way around: the Scala.js compiler is over optimizing for the JS backend.

Closures have two separate uses ATM IIUC:

• JS functions. This is not going away.
• An optimized representation for Scala lambdas. This is what this PR is about.

The compiler is making the decision to perform the second optimization. However, it seems to only be an optimization that works well for the JS backend. This makes sense, since it has native support for lambdas, whereas WASM doesn't.

How would the world look, if we instead moved the Scala lambda optimization from the compiler to the JS backend?

IIUC to decide whether we can emit a Scala X class as a closure:

• We need to make the decision globally
• X may only have a single instance method.
• X may only have a single instantiation site (and a fortiori only a single constructor in use).
• X may not have subclasses.
• X may not have runtime data.
• X may not have instance checks.

It seems to me that this is quite similar to the inlineable init optimization. And it also seems it has the potential to allow for more optimization (n.b. post optimizer closure optimization or closure optimization for classes where only a single method is used).

WDYT?

Ah and I forgot: IIUC if we do this, then the WASM backend shouldn't need any adjustment at all, because "typed closures" are just classes at this point (and IIUC the runtime layout would be quite similar, except for the vtable/typedata pointer overhead).

Additional 2 things I forgot:

• toString
• "external" reading of fields

Identifying all these conditions would be really tricky. Just toString poses a significant issue because the default uses getClass.getName. I don't think reverse-engineering classes this way would be effective.

However, we could go the other way: not creating a class at all, and instead have a LambdaMetaFactory-like opcode. It would take one superclass or super interface, one method to implement, and a pointer to a method that implements it (or a Typed Closure). Then the linker materializes whatever it wants to implement this concise spec. This is essentially what happens on the JVM.

One benefit is that we can then apply the best optimization also for SAM interfaces other than Scala functions (e.g., Runnable). That might mean that the linker synthesizes a closure-carrying class per pair (superclass, method-to-implement).

In terms of code size, even for Wasm the single class carrying a Typed Closure is very beneficial. So expanding full classes is not necessarily the best strategy.

As far as I can tell, the best strategy would be a closure-carrying single class, with optimized dispatch that eagerly type-tests for that single class. So when calling a Function1.apply, dispatch would test whether it is actually a Unique$Function1. If yes, directly call the closure it carries, otherwise, perform interface dispatch.

That is something we could do with an LMF-style opcode, which we would have a hard time reverse engineering from already expanded classes.

@gzm0 I added a commit that introduces NewLambda as a new IR node that mimics a LambdaMetaFactory. It synthesizes the required anonymous classes at link-time, based on a Descriptor and a typed closure. That notably removes the need for the hard-coded TypedFunctionN classes. It is also generalizable to SAM types such as j.u.Comparator, although I did not implement that yet.

As the commit message says, the implementation on the linker side is butchered at the moment. The idea is to support discussion of the IR changes at the moment.

WDYT? If we add generalization to SAM types, this would also improve JS: all the lambdas for j.u.Comparator (for example) in the codebase would be able to share a unique anonymous class, like we currently do "by hand" for AnonFunctionNs.

I think the NewLambda tree looks very promising, both in terms of simplifying the compiler and in giving more semantic information to the linker.

What I'm wondering is whether it is worth keeping the TypedClosure abstraction in the core IR: if we could only have NewLambda the complexity increase in the IR would be minimal. (if it helps the optimizer, we could still consider introducing typed closures as transients).

I don't think we can remove TypedClosures. The deduplication of NewLambdas needs them. If we don't have typed closures, then the NewLambda.Descriptor must also contain a target method name, in addition to a list of capture param types. The problem is that those will be different at virtually every call site. That means Descriptors are never the same, and every lambda will get its own class, defeating the entire purpose of NewLambda.

I don't think we can remove TypedClosures. The deduplication of NewLambdas needs them. If we don't have typed closures, then the NewLambda.Descriptor must also contain a target method name, in addition to a list of capture param types. The problem is that those will be different at virtually every call site. That means Descriptors are never the same, and every lambda will get its own class, defeating the entire purpose of NewLambda.

Ah, sorry, I wasn't clear. I understand that we need a closure and a descriptor param to NewLambda and that we want the closure to be inline (so not a reference). However, do we need to support first order TypedClosures or can we only allow (and require) them as inputs to NewLambda? This would remove the TypedClosure type and the TypedClosureApply node.

It might mean that we have to fall back to a full class when we need bridges for SAMs, but maybe that's OK?

Ah, I see. So something like

case class NewLambda(
  descriptor: Descriptor,
  captureParams: List[ParamDef],
  params: List[ParamDef],
  body: Tree,
  captureValues: List[Tree]
)

(note that params is required outside of the Descriptor to relate the names of the params found in body)

That can work from an IR-only point of view, indeed. The main issue is that it's not clear how the BaseLinker should then desugar the NewLambdas.

Currently it generates a field of a ClosureType, a constructor taking a ClosureType{,Ref} as argument, and an ApplyTypedClosure. All of that is currently valid input to the IR checker, which can accurately validate that the closure types match. If we don't have closure types in the type system, it's unclear what to do. What type do we give to the field? How do we encode the type of the constructor parameter? Do we then need TransientType? If yes, how does the IR checker validate that transient types follow typing rules?

My hunch is that answering these questions will yield a design that is even more complicated than having ClosureTypes in the legitimate IR.

The main issue is that it's not clear how the BaseLinker should then desugar the NewLambdas.

Ah, I haven't looked that far. Are we sure we want to desugar the lambdas? It feels to me:

• The optimizer would benefit from seeing lambdas (inlining hints, etc.)
• The module splitter would benefit from seeing lambdas (there is a trade-off between duplicating a lambda sugar and introducing more module dependencies).
• Expanding the lambdas in the backend only shouldn't be too hard?

I'm pretty sure we want to desugar the lambdas. If we don't, then every analysis and optimization that relates to the class hierarchy analysis gets more complicated. Figuring out the analyzer's job, in particular in the presence of reflective proxy and/or default methods, gets really tricky. In the optimizer, a method call now needs to handle actual target methods as well as hidden methods of lambdas. Currently there are very few changes in the optimizer, and they're all somewhat duplicating for TypedClosures what we do for Closures. If Lambdas survive until then instead, that will complicate core mechanisms like function calls and inlining.

I see, yeah that makes sense. So maybe what could be an in-between option is to disallow (free-standing) TypedClosures trees and types in serialized IR? This is somewhat similar to records (whether to have a TypedClosure inside a NewLambda or flatten it is TBD).

This way, we can use TypedClosures in the linker pipeline but do not unnecessarily increase the IR interface.

That seems doable. It will require a bit more work in the javalib IR cleaner (it currently lowers Scala functions to the underlying typed closures, but it could be custom functional interfaces instead), but nothing too dramatic.

@gzm0 This is now stand-alone and reviewable again, after rebasing on the merged #5101.

I just realized that I do not understand at all, why we still need custom box processing in GenJSCode with this change.

My understanding of the situation before this PR is that we use untyped closures to represent lambdas. As a result, we need to adjust boxes because the closure boundary requires boxed types (anys). However, with this change, we lift this limitation, so we should (?) be able to take the types scalac generates directly. As such, I would expect the necessary boxes to be already present.

Just TBC: I do understand that boxing/unboxing can/will be required between the specific interface a method implements and its implementation, and potentially even between the Function node and the delambdafy target. What I do not understand is why the Scala.js backend needs to handle this at all (or does the JVM backend do similar things and it is "just like that"?).

I'll try to keep digging some more about this, but any help is appreciated.

Yes, the JVM backend has to do a lot with that as well. The backend itself doesn't do much. The work is split between another phase (delambdafy, which is after our backend), and the JVM's LambdaMetaFactory, which can handle boxes/unboxes that follow Java rules. We don't have the phase, and our NewLambda doesn't deal with boxes, so the work to handle that is concentrated in the backend.

It's a bit tricky to review ATM because of the rebase on the name refactoring (using commits for both review history and intended target history at the same time is not working too well with Github's comment tracking).

Sorry. I expected #5136 to be mostly a no-brainer that would be quickly reviewed and merged 😅

Thanks a lot @gzm0 for reviewing this deep PR over the months!