Hello, before I get too far, I come from a C++ background.
I'm designing a general event-driven server, and I have a design choice to make. As the title states, I'm concerned about the ownership scheme of objects that are used in various events (some of which may linger for a while before it's time for them to be called). Since some events can have a delay before they are executed, I'm wondering how to deal with them should they live longer than their owners. I'm faced with a couple obvious solutions:
1) Keep a reference to the event on the object that 'owns' it and remove it from the event queue when its owner dies. This would mean iterating over the event queue searching for the element to remove (linear complexity?) as well as maintaining a list of events on the owner.
2) This is the one that I'm fuzzy on... Maintain the event's owner as a weak reference in the event and let it naturally die (start returning a null referant, if I read the documentation correctly) and have the event exit early if its owner has died. I take that the system is not like reference counting like in C++, as the time that the reference is reclaimed by the GC is undefined. I suppose the question about solution # 2 is: Since the garbage collector can determine if an object is "Weakly Reachable", can I do the same with my application code without reinventing too much of the wheel?
The thing that sets me off-base with this problem is that I have a hard time just sitting back and praying that the references running loose in my program behave correctly.
Any solutions / comments about my problem?
Developer suffering from a language transition
I've also encountered a problem with GC pauses in my preliminary testing. It seems that no matter what kind of tuning that I do, the best that I can do is delay the "stop the world" pauses. Is this behavior just something that Java developers live with? The only truly pauseless GC that I've seen in my searches is Azure's 4C garbage collector that runs in their Zing JVM.
Luc Lieber wrote:1) Keep a reference to the event on the object that 'owns' it and remove it from the event queue when its owner dies...
I guess my question would be: is the act of 'dying' an explicit thing or not - or could you make it so?
The problem with using a WeakReference is that an event could still be called on an owner that is essentially dead (ie, not strongly referenced, but not yet checked by the garbage-collecter), whereas if owners were actively "finalizable", they could manage their own events (and in turn, events could manage the queue(s?) they belong to).
If calling an event on a "basically dead" owner isn't an issue, then a WeakReference will probably be fine; otherwise you might want to have your owner class (and maybe your event class too) implement something like java.io.Closeable.
It does occur to me that you may be worrying about nothing though. How many of these owner classes are you expecting to be hanging around "after their time": hundreds or billions?
If the first, I suspect that the best thing would be to just include a hard reference in the event and leave them to die naturally; if the latter then you might need something like WeakReference. In between: you're probably the best judge; but don't forget that increasing complexity also increases the chances of you making a mistake in memory management (kind of like the Heisenberg principle).
Isn't it funny how there's always time and money enough to do it WRONG?