Provide a way to gather static initializers

[davidmorgan]

Some frameworks need a way to run initialization code for all leaf code using the framework. For example, dependency injection frameworks want to build a map of injectable types, and serialization frameworks want to know about all serializable types.

Currently frameworks either use codegen or manual initialization to do this.

I discussed with @eernstg and @sigurdm; the idea we got to was that it might be possible to build this on top of existing const canonicalization support, giving something that's both cheap to implement and sufficient for the use cases we care about.

Leaf code wanting to register itself would declare a const in some new special way:

@register
const unimportantName = 'value';

@register
const otherUnimportantName = 'otherValue';

When the framework is initialized it can ask for all @registered const values and iterate over them doing whatever initialization work it wants to.

  var registrations = Platform.registeredConsts(); // <Object>['value', 'otherValue']

This is sufficient for e.g. all injectable types or serializable types to register themselves. Note that the value registered could be any const, e.g. a function, or an instance of a const class. A possible refinement would be to make it possible to ask for all registered consts of a particular type:

  var registrations = Platform.registeredConsts<String>(); // <String>['value', 'otherValue']

--arguably this removes the need for the register annotation since you can request a framework-specific type that is only used for registration.

[jakemac53]

The implications on treeshaking and modular compilation should be carefully evaluated here.

For treeshaking, any app using these methods would have to retain all annotated consts, regardless of if they are ever actually used.

For modular compilation, any library using these methods now has a dependency on effectively all transitive libraries (any library could add a new const at any time).

[matanlurey]

Angular was originally built this way, and it was a huge [expletive] mistake.

I understand it "feels" nice to be able to do aspect-oriented programming like this, but it does not pay off when you care about code-size and initial startup, as Dart's users do.

[eernstg]

I've written an outline of a feature that I've put together, #371, based on the discussions that we had at the summit, and input from several others.

It uses a new kind of declarations Set<T> S of const; that goes into the framework (say, in library L). Each contributor to S must be in a library that imports L, and then it can do const S.add(c); where c must be a constant. S is immutable but not constant, and the main point is that the framework can get access to a bunch of values without depending on all the libraries that those values came from.

There is no control other than "exists in the program". So if you import L1 anywhere and that library adds something to S then you will have it in S at run time (there is no notion of tree shaking or such, and it's not easy to say how you'd achieve that; so take care).

It's up to some code in main (or something called from there) to make anything "interesting" happen: The #371 feature only allows us to gather a bunch of constants into a set. They might be functions used to perform some initialization, and some framework function initialize(...) could then be called in order to perform that work at an appropriate time. Again, some manual coding is needed in order to allow the work to take place in a lazy manner, but that's all done in user-written code, so the framework developers can set up whatever mechanism they want.

#371 covers link time maps as well. I suspect that it wouldn't be much harder to support than link time sets, and this might be a useful basic "mechanism" in the above sense.

[sigurdm]

I agree that it would be breaking modularity, and I in general feel iffy about the fact that the presence of an 'import' can change the semantics of a program.

Wrt. modularity: One solution for DDC would be to generate a static initializer for each library that registers global consts and is run by before main at program startup time (I suppose it already does something like this for constant canonicalization).

The advantage of this compared to general static initialization is that const evaluation has no side effects.

Angular was originally built this way, and it was a huge [expletive] mistake.
Can you elaborate on this?
What where the exact things that went wrong for Angular?

[davidmorgan]

Thanks Erik! That looks like a good fit.

Re: tree shaking, I expect that frameworks will provide custom tree shaking code. This is already being looked at for protos. My intuition is that a whole program kernel transform is the correct place to do this work.

Re: modular compile performance, these collections should only be accessed in framework initialization code, which should have a 1:1 correspondence to app entrypoints. Compilation performance should be better than what we have today--because today we are implementing something like this on an ad hoc basis. The compiler should be able to do it more quickly since it already does this work for const canonicalization.

Re: angular. Code size should be addressed by custom tree shaking; startup time needs consideration. If the initializer list is "flat" then startup time will necessarily be proportional to the list size. But the proposal allows for a map; if this is set up so initialization can be done lazily based on the key, then I think startup time should be okay.

I think a good next step for the proposal would be for CFE folks to check if my hand waving about "custom tree shaking code" is at all feasible :) ... I'm not exactly sure what form this would take, but protos are a good example. e.g. perhaps the app needs to supply some additional data at compile time to help the tree shaker figure out what to keep; it could for example say "these packages are the feature code; tree shake const initialization exactly for protos not mentioned here".

[eernstg]

@matanlurey wrote, and @sigurdm commented on:

Angular was originally built this way, and it was a huge [expletive] mistake.

I'd also like to hear more about what went wrong.

Note that the mechanism in #371 will not give rise to additional space for constant objects (every object which is added to a link time set/map is obtained from a constant expression, and presumably you'd need that constant anyway), so the only added space consumption is for some sets/maps to hold those values. Also no computation takes place before main is executed, except for add on a platform set type and operator []= on a platform map type. No user code runs. So the mechanism in itself should not be expensive, and certainly not unpredictably so.

We could store anything in those sets/maps as long as it is a constant, but I'd expect things like functions (that some initialization code in the framework would call, when appropriate) or objects that could be understood as commands (so maybe there's a list of k values, a list of k types, and a function, and then the initialization code should call that function as with those arguments, that is, f<Tj>(vj), with j in 1..k). Such commands and their "interpreter" in framework the could be tailored to allow any kind of laziness that the situation calls for, so we shouldn't need to change the link time sets/maps themselves in order to avoid having a long start-up time.

Was there something in the original approach taken by Angular which would still be inherently difficult to handle?

[sigurdm]

re: tree-shaking
I have been speculating in a feature that would allow marking an expression a "weak" reference wrt. tree-shaking.

Meaning that it would not count towards keeping objects alive, and would return null if what it referenced was tree-shaken away (because it is not referenced anywhere else).
I don't know exactly how such a thing could be formalized (currently treeshaking does not have observable effects on program semantics), and not sure how easy it would be to use.

[eernstg]

@sigurdm wrote:

re: tree-shaking

In this context I envision a typical situation where the link-time sets and maps are rather small, because they would typically contain a bunch of functions to run, or a bunch of "command" objects (again specifying some computation). Running those computations might be very expensive, but it should be possible to partition the tasks into manageable chunks and running them on-demand. Couldn't this enable the same kind of resource usage improvements as a tree-shaking feature? We wouldn't run a command before we need the data that it produces, so if it's never needed we've "tree-shaken" it away.

Of course, it might be a complex task to partition the "start-up" computations and perform them lazily at the right point in time, but it would be done in regular Dart code so we can use whatever techniques we can think of.

[yjbanov]

@eernstg

presumably you'd need that constant anyway

This assumption is wrong, and it is where the Angular approach fell apart. The issue was that a library would statically declare 10x@Injectable and/or 10x@Component and/or 10x@Directive classes. However, of those 30 classes only one would be used by a downstream application. Since all these classes were aggregated into a top-level Map<Type, TypeFactory> the tree-shaker couldn't remove any of the classes (TypeFactory is a function that instantiates the class). The map could be iterated over and TypeFactory called.

Note that there was a similar attempt in the past by @sigmundch (but never got adopted). The idea was to provide a new kind of map, LookupMap, which could only be const and only allowed key lookups. Iterating over the map would be banned. The tree-shaker would compute the union of all keys that could possibly flow into this map and remove unused key/value pairs. This gives you a semblance of having reflection into a library but in a tree-shakable way.

[matanlurey]

This should straight up and simply not be done. It is a mistake. Interestingly enough, I don't see much of a problem statement here, only a solution. We've talked to lots of teams both externally and internally before who thought they wanted this, only to be (easily) talked out of it when the costs and benefits were weighed out.

(While it seems simple enough at constants, ultimately teams will want to register non-const objects and functions, and then all assumptions are completely out of the window as you have accidentally implemented mirrors by another name)

@davidmorgan:

Re: tree shaking, I expect that frameworks will provide custom tree shaking code. This is already being looked at for protos. My intuition is that a whole program kernel transform is the correct place to do this work.

This is a terrible expectation. Writing a generator is tough enough, expecting teams and frameworks to write global analysis steps is, full-stop, a non-starter. The only reason it works for protos is because of the small scope of the project (only for the VM, and written/maintained by the Kernel/VM team).

Re: angular. Code size should be addressed by custom tree shaking

Sorry, this is just a really bad assumption and idea. I don't have a better way of stating it. We spent literally 5 years thinking of different ways to mitigate the cost of collecting metadata and decided the only way forward was to deprecate it (initReflector()).

@eernstg:

I'd also like to hear more about what went wrong.

There is a bit of history in these docs:

• https://github.com/dart-lang/angular/blob/master/doc/faq/component-loading.md#background
• https://github.com/dart-lang/angular/blob/master/doc/faq/dependency-injection.md#overview

I'd be happy to GVC/meet in person to go over details.

[mkustermann]

I don't see much of a problem statement here, only a solution.

This discussion originated with a very concrete problem: Decoding protobuf messages with extensions, where the decoder doesn't know about which extensions are available. See b/131893790 for further details.

Writing a generator is tough enough, expecting teams and frameworks to write global analysis steps is, full-stop, a non-starter.

That depends, on the project, the team and the benefit it brings. If there is a huge savings in size or increase in performance, a "full-stop, non-starter" becomes "the right thing to do".

Given that Angular seems to have a similar problem: What solution do you currently use? What solution do you recommend?

[matanlurey]

This discussion originated with a very concrete problem: Decoding protobuf messages with extensions, where the decoder doesn't know about which extensions are available. See b/131893790 for further details.

IMO, this is a flaw in how the protobuf library was originally developed, not in Dart. For example, @yjbanov's original gAPI-compatible "Streamy" library (now deprecated) never had this problem, if you didn't use certain entity objects (read: protos) or fields, the information about decoding/encoding them was tree-shaken. This was back in Dart 1.x to boot.

(As far as I can tell, the JSPB/JS-Closure solution internally also supports tree-shaking w/o hacks)

Given that Angular seems to have a similar problem: What solution do you currently use?

A combination of things:

• We accept we can't do extremely fine-grained tree-shaking.
• We tell teams to import and use exactly what they need, instead of relying on the framework.

As how this relates to protocol buffers, I am not sure there is an easy fix. I know @ferhatb and others have talked about having a "Nano Proto" or "Proto lite" library similar to what was developed for Java internally, and I'm a huge proponent of this idea.

[sigmundch]

I think it's worth exploring whether there is a protobuf specific design for the problem of extensions, first. For example, as @jakemac53 suggested elsewhere, could decoding be more lazy when it encounters extensions?

Indeed, if we do end up considering static initializers, we need to be extremely cautious about tree-shaking. I also want to share a couple thoughts from previous approaches:

• initialize package: we once had a package that added static initializers as a transformer. The logic is now outdated (it was based on the barback-transformers that are now deprecated), but it should illustrate that approach: methods annotated with @initMethod were called at the beginning of main. We created it to support polymer, which needed actual code to be able to register custom elements before starting the app. This work suffered from the same drawbacks mentioned earlier on this thread: annotated methods couldn't be tree-shaken, it required scanning the entire app to generate a list of initializer calls and invoke them in sequence, and new imports and other unrelated changes were able to affect what was called and in what order.

• lookup maps: which @yjbanov mentioned earlier, were tree-shakeable const maps. They worked under the assumption that keys could not be retrieved from the map (these maps didn't support iterating them) of fabricated at runtime. That ensured that a compiler could statically determine if a key was used anywhere else in the program, and if not, the corresponding row in the map would be deleted. I think this approach won't support protobuf extensions because I believe extensions keys are just numbers or something that can be fabricated at runtime, so we wouldn't know whether something could be tree-shaken.

• I'm less famliar with Angular's inner workings, but it's worth highlighting that their dependency injection used to rely on generating initReflector initializer methods called recursively from main. Recently they have pushed customers to be more explicit about their dependencies and use runApp instead. My understanding is that the former allowed you to create a registry that couldn't be tree-shaken, hence projects noticed at least a 10% code-size reduction when switching to use runApp.