some Promises(?) not being garbage collected

[warner]

I'm investigating a performance problem in our xsnap-based vat environment. In my test, I send a delivery into the vat, which does a fixed amount of work, and resolves a promise to indicate that it is complete. At the end of each delivery, our code forces a GC cycle. The symptom is that the GC cycle takes more and more time: it seems linear in the number of deliveries we've made. I added a line to print the->currentHeapCount, and it is growing (5 slots per cycle), indicating that something is not being garbage collected, and the ever-growing heap size would explain the longer GC cycle, which would explain the performance degradation.

I've narrowed the problem down to deliveries that perform an eventual-send using our HandledPromise implementation. I added a FinalizationRegistry to track some of the more visible Promises, and that reports them as being collected. I've also ruled out the handful of tables that we use to track these promises: their size remains constant.

We saw a similar bug before, and you were able to track it down to something in the Promise implementation that was failing to mark either a Promise or a handler function as free, in a particular situation that was provoked by our HandledPromise implementation. That bug was fixed back in June, in commit 22116a6. I'm guessing that this might be another variant of that bug.

I'm assembling an XSNAP_TEST_RECORD trace of the run for you to recreate the issue locally, I'll attach it here somehow.

[warner]

https://gist.github.com/warner/726935311e0c0dbfd1417401e1082862 contains the replay log and details on the runtime versions.

[dckc]

re xsnap-pub version "...which should be pretty close to the version we got from Moddable", we're now keeping in sync with Moddable folks on all changes to xsnap-pub. They regularly review any changes we make.

[phoddie]

This has been tracked down to a problem with Map/Set when deleting items with an iterator active. Fix is pending.

[phoddie]

Closing as email discussions indicate this problem has been resolved.