Win a copy of Emmy in the Key of Code this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Object Ownership

Posts: 14
C++ Notepad Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Posts: 21817
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that WeakReference is what you're looking for. You create one with your "owner", then get() will return this owner, or null if the owner has already been garbage collected.
Posts: 10777
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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

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).

It's fun to be me, and still legal in 9 states! Wanna see my tiny ad?
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!