Recycle actor heap chunks after GC instead of returning to pool

[dipinhora]

Before this commit, any unused chunks after actor heap garbage collection would be destroyed and returned to the memory pool immediately for reuse by the runtime or any actor.

This commit changes things so that instead of destroying and returning the chunks immediatelly, we assume the actor will likely need more memory as it runs more behaviors and keep the recently unused chunks around in case that happens. This is generally more efficient than destroying a chunk and getting a new one from the memory pool because both destorying a chunk and allocating a new one involve updating the pagemap for the chunk to indicate which actor owns the chunk. Updating the pagemap is an expensive operation which we can avoid if we recycle the chunks instead. The main drawback is that since actors will no longer return chunks to the memory pool immediately after a GC, the overall system might end up using more memory as any freed chunks can only be reused by the actor that owns them and the runtime and other actors can no longer reuse that memory as they previously might have been able to.

[SeanTAllen]

our normal pattern in the codebase is to compare to NULL as the second item. Is there a reason for the variance in this patch?

[dipinhora]

no reason except that i accidentally forgot an = and didn't notice and that's much easier to track down with the condition written this way..

[SeanTAllen]

I see this will free any recycled chunks that aren't reused after 1 gc pass.

Can you help me work through how this will work in practice. If an actor never gets gc'd, this won't have any impact. If an actor only got gc'd once, then some unknown amount of memory would not be freed, and if the actor is gc'd more than once, the same would still apply, some amount of memory would continue to be held for recycling. Yes?

[dipinhora]

I see this will free any recycled chunks that aren't reused after 1 gc pass.

Can you help me work through how this will work in practice. If an actor never gets gc'd, this won't have any impact. If an actor only got gc'd once, then some unknown amount of memory would not be freed, and if the actor is gc'd more than once, the same would still apply, some amount of memory would continue to be held for recycling. Yes?

correct..

• if an actor is never gc'd, it doesn't matter
• when an actor is gc'd, new unused chunks get saved for recycling, old chunks saved for recycling that were never reused get returned to the runtime memory pool
• if an actor gets destroyed (by the cycle detector or some other mechanism), any chunks saved for recycling get returned to the runtime memory pool
• if an actor blocks, any chunks saved for recycling are "stuck" in the actor/not returned to the runtime memory pool and cannot be re-used by the rest of the runtime or another actor

that last point is where there's possibility of tweaking things by having the actor return any chunks saved for recycling to the runtime memory pool instead of continuing to hold onto them when it blocks..

[ponylang-main]

Hi @dipinhora,

The changelog - changed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.

Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 4531.md to match the number of this pull request.

The basic format of the release notes (using markdown) should be:

## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.