Prepack: Besides global code, support prepacking additional independent functions

[NTillmann]

Consider global code like this:

initStuff()
initMoreStuffA()
initMoreStuffB()

Assume that initMoreStuffA() and initMoreStuffB have the following properties:

1. they do rely on the effects of initStuff
2. they do not effect each other, e.g. initMoreStuffA does not read or write any heap location that initMoreStuffB writes to, and the other way around.

It seems that we should be able to detect the 2. property.

Now assume that the global code changes, so that initMoreStuffA and initMoreStuffB don't actually run as part of the global code, but get invoked conditionally. We should be able to prepack the two functions separately, and serialize code for them that patches the heap appropriately.

[javache]

This looks great. For our use-case specifically, A and B will be independent but may be writing to shared parts of the heap.

functon initStuff() {
  global.registry = {};
}
function initMoreStuffA() {
  global.registry['A'] = 'a';
}
function initMoreStuffB() {
  global.registry['B'] = 'b';
}

Another property that would hold true for this is that.

initStuff()
initMoreStuffB()
initMoreStuffA()

will result in the same heap layout as the original.

[hermanventer]

I'll take on the bits needed for checking that initMoreStuffA and initMoreStuffB are independent from each other.

[NTillmann]

Decomposing the overall required work:

1. Add option to Prepack to identify a set of function on the global object which should get handled, and then exploring them separately for effects after the global code is done.
2. Build a checker to determine that effects are mutually disjoint (Herman volunteered for that).
3. Enhance serializer to rewrite those functions for the special case that they are pure, i.e. do not mutate any shared state.
4. Enhance serializer to rewrite those functions in the general case, taking care of general effects, including mutations of shared state.

3 by itself seems to be a very useful feature, and should be strictly easier than 4.

[NTillmann]

1. Is done by #846.
2. Is done by #850 and #857.
3. Is done by #912.
4. Is still missing, with remaining work outlined in #987, #988, #989, #990.

[NTillmann]

988, #989, #990 are done.

Still open is #987.
Recently new issues surfaced and are still open: #1250 and #1238 and #1140 and #1093.

[NTillmann]

988, #989, #990, #1238 are done.

Bugs still open are:

• Incorrect sharing of bindings of residual/additional functions (#1250)
• Rework #1107 to work and be cleaner (#1140)
• Make additional functions capture precisely the values they need (#1093)

New feature requests:

• Make Additional Functions work with arguments (#987)
• Support multiple additional functions updating a binding (#1087)
• Support for nested additional functions (#1398)

[NTillmann]

988, #989, #990, #1140, #1238, #1093 are done.

Bugs still open are:

• Incorrect sharing of bindings of residual/additional functions (#1250)

New feature requests:

• Make Additional Functions work with arguments (#987) --- first basic version is working!
• Support multiple additional functions updating a binding (#1087)
• Support for nested additional functions (#1398)

[cblappert]

I think the goals specified in this PR are mostly achieved. Additionally, this specific use case is no longer needed, so I'm closing this task.