Tasks / Mailbox garbage collection

37 views
Skip to first unread message

Jason Pell

unread,
Mar 15, 2013, 8:45:58 PM3/15/13
to kilimt...@googlegroups.com
Hi,

I already have posted a message about poison pills process, but I figured I would try and target my question more appropriately.  I just want to ensure
I don't have a memory leak when I take a actor tree out of service, but removing any reference to the first inbox in the tree from my application.

If a mailbox is no longer getting messages and there is no longer a reference to the first mailbox in a actor tree, is there anything that continues to hold
onto references to prevent garbage collection?   I am still digging through the kilim code but thought I would ask.

I had thought I might need to do proper stop processing, but if I remove any reference to the starting node, my application no longer has access to the
kilim actor tree and related mailboxes.

From what I can tell, the scheduler does not hold onto tasks unless they have been scheduled to run, by calling resume after one of the mailbox
listeners is fired (MsgAvailableListener or SpaceAvailableListener)

The mailbox and actors reference each other, so will that actually prevent them being garbage collected?  It is a recursive reference and I am no
garbage collector expert?

If they won't be garbage collected because they still reference each other, what is the best way to deal with that?   Would I need to extend Mailbox
to get access to the listener members so I can clear them out?


jason...@gmail.com

unread,
Mar 15, 2013, 8:53:08 PM3/15/13
to kilimt...@googlegroups.com
I should have done some googling first :-(

http://stackoverflow.com/questions/1910194/garbage-collection-in-java-and-circular-references

So can I confirm with the mailing list kilim experts. If I remove any
reference to the first mailbox in the tree, is there anything else
referencing these mailboxes and tasks (other than themselves via the
listeners) that is going to prevent garbage collection, or will they
all be silently garbage collected without an issue?
> --
> You received this message because you are subscribed to the Google Groups
> "kilimthreads" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kilimthreads...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Sriram Srinivasan

unread,
Mar 16, 2013, 4:28:29 AM3/16/13
to kilimt...@googlegroups.com

> I already have posted a message about poison pills process, but I figured I would try and target my question more appropriately. I just want to ensure
> I don't have a memory leak when I take a actor tree out of service, but removing any reference to the first inbox in the tree from my application.
>
> If a mailbox is no longer getting messages and there is no longer a reference to the first mailbox in a actor tree, is there anything that continues to hold
> onto references to prevent garbage collection? I am still digging through the kilim code but thought I would ask.
>
>
>
> The mailbox and actors reference each other, so will that actually prevent them being garbage collected? It is a recursive reference and I am no
> garbage collector expert?
>


There's no magic. Your intuition is correct; the task and mailbox may refer to each other (and only during a get or a put), and will be collectively gc'd if there's no other referrer. Once a task is paused because of a get (for example), the task is added to the mailbox's 'sink', and the task holds on to the fiber. If no one's stored a ref to the mailbox, both the task and the mailbox will be silently gc'd.

You are also right that the scheduler only knows about runnable tasks, but not paused tasks.


> If they won't be garbage collected because they still reference each other, what is the best way to deal with that? Would I need to extend Mailbox
> to get access to the listener members so I can clear them out?

There's no need to do this.

"If there's a task waiting in the forest and there's no one to notice, does it exist"? Ancient philosophical issue.

--sirram

Jason Pell

unread,
Mar 16, 2013, 6:42:39 AM3/16/13
to kilimt...@googlegroups.com
Hi,

Thanks for your reply, now I can get rid of my stop() methods as my
tasks were already being garbage collected.
Reply all
Reply to author
Forward
0 new messages