commit 52793886a0a25802984e8cf5831b587ec3822aa3
author Jens Johansen <jensj@google.com> Fri May 29 09:48:28 2020 +0200
committer Alexander Thomas <athom@google.com> Wed Jun 03 12:22:34 2020 +0200
tree 8ce42445db47e704d6ac58ab2f1671a6b63c7b01
parent c0e3e5dc83a7977421de8c1e56407ead96a7a819

[frontend_server] Plug leaks caused by saving the first compilation result

The first compilation result is leaked in two ways:
1) Directly by saving the component in a variable; and
2) Via an unfortunate context thing, probably a variation of
   http://dartbug.com/36983. I will update that bug with a reproduction
  example later.

The reason this creates a (big) leak is illustrated with an example:
* Say the first component (A) has 10 libraries in it. Each of these
  libraries has parent pointers and points (currently) to A, which again
  points to all of the 10 libraries.
* We then do a recompilation, say 5 libraries are reused and 5 are new.
  They are put into a component (B). We really should have 10 libraries,
  the 5 old ones and the 5 new ones (and for simplicity lets say these are
  the ones in B). Notice that the 5 old ones will have their parent
  pointers updated and also still be in the list of libraries in A.
  We keep 15 libraries alive because we have the 10 original ones saved via
  A and the 10 (where 5 is new) saved via B.
* We then do a recompilation, say 2 of the same libraries as was also
  recompiled before, these end up in compnent C which has 5 libraries from A,
  3 libraries from B and the 2 new ones. All of these libraries will have
  their parent pointers updated to point to C.
* Because we saved A we keep all the 10 libraries in A though.
  Because we saved A and some of the libraries in A had parent pointers
  updated to point to B we also keep B and all libraries in B.
  Because we keep B and some of the libraries in B had parent pointers
  updated to point to C we also keep C and all libraries in C.
  So instead of only having the 10 "live" libraries, we have 10 + 5 + 2 = 17
  libraries, a leak of 7. With more compilations this keeps happening and
  the leak keeps growing.

This CL stops the leak by not holding on to A (which, in turn, stops holding
on to B etc.)

Change-Id: If4f8b1e240b7c39f084df9cb2690570ff26fa9b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149280
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>