You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Trigger GC for actors when they tell the cycle detector they're blocked (#3278)
Prior to this commit, if an actor blocked, it did not run GC to free
any memory it no longer needed. This would result in blocked actors
holding on to (potentially lots of) memory unnecessarily.
This commit causes GC to be triggered when the cycle detector asks
an actor if it is blocked and the actor responds telling the cycle
detector that it is blocked. This should result in memory being
held by blocked actors to be freed more quickly even if the cycle
detector doesn't end up detecting a cycle and reaping the actors.
This will force a GC for an actor based on the following three things:
* The actor processed at least one message since it's last GC (i.e. it did some work [GC acquire/release message or app message)
* The actor's heap is greater than 0 (i.e. it has memory that could potentially be freed)
* The actor is blocked and is about to tell the cycle detector that it is blocked (i.e. it thinks it has no more work to do at the moment)
The sequence of events for GC'ing when sending a block message to the CD is:
1. actor gets a message from another actor
2. gets rescheduled because it processed an application message
3. next run has an empty queue (and the actor gets marked internally as blocked but doesn't send a block message to the CD)
4. some time passes and the CD eventually asks the actor if it is blocked
5. the actor garbage collects because of this change before sending the block message to the CD (to prevent race conditions)
6. the actor responds to the CD by sending a block message
This shouldn't be a performance hit because step 4 is based on how often the CD runs (not very often) along with the fact that the CD doesn't ask all actors it knows about if they're blocked on every run, it asks them in batches instead and so step 4 will not occur very frequently for any actor even if steps 1 - 3 happen regularly.
0 commit comments