hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Francois Poilpret" <>
Subject RE: Potential memory leak with Threaded model and Events listeners
Date Sat, 04 Dec 2004 17:18:27 GMT
Hi Luke,

Thank you for your remark.
Although your remark is correct in many cases of Listeners, I think it would
generally not apply in HiveMind context, I mean (if people follow the "right
path") that normally, only a service will implement a Listener interface,
thus at least HiveMind itself (through one of the generated proxies) will
hold a strong reference to that service/listener. But of course, if someone
decides to create a Listener on-the-fly and add it "by hand" to the event
supplier service, then the problem you described would occur.

Anyway, I just did some tests (with strong and with weak references) and in
fact, the result is not "as good" as I expected initially. Indeed, when
suggesting that idea, I simply forgot that the handling of weak references
is totally non-deterministic, ie the weak ref could still be valid even
though there is no more existing strong ref. The time at which the weak ref
would be cleaned is totally up to the GC...
So as my test have shown me, using weak refs improve the issue, but they do
not solve it really:-(

In my tests, I did something like that:
- create EventSupplier service (singleton)
- create EventConsumer service (threaded)
- instantiate EventConsumer in 1000 "threads" (they are real threads but
they do not run concurrently, but I force consecutive runs, with a call to
Registry.cleanupThread() at the end of each thread)
- each thread call the EventSupplier to generate a new event
- all calls are traced
- each EventConsumer instance allocates 10KB on the heap and never release

With strong refs:
- the 1000th thread sends an event that is received by 1000 EventConsumer

With weak refs:
- the 1000th thread sends an event that is received by about 30
EventConsumer instances.

Of course that is much better, but the ideal, here in my testcase, would be
always just one EventConsumer instance receiving the event.

So finally, maybe I will stick with the previous -not very clean from design
viewpoint- workaround:
- have EventConsumer implement Discardable and remove itself from the
EventSupplier list of listeners, when threadDidDiscardService() is called.

And then I will eagerly wait for HM1.1 release (hope it will fix this


-----Original Message-----
From: Luke Blanshard [] 
Sent: Saturday, December 04, 2004 8:13 PM
Subject: Re: Potential memory leak with Threaded model and Events listeners


The problem with holding listeners weakly is that people commonly create 
listener objects on the fly and then retain no other references to them 
once they've added them.  So these listeners are thrown away on the next 
GC cycle, and they stop working.

One solution to this is to have a tagging interface (we call ours 
WeakListener) that tells the event source that it should hold the 
listener weakly.  All listeners that don't implement this interface are 
held strongly.  This way, you as the implementer of the listener are 
telling the event source whether to hold the listener weakly (meaning 
you better have a strong reference to it) or strongly (meaning you don't 
have to).  As you say, it's pretty easy to write a listeners collection 
that honors this WeakListener interface and throws away the expired 
listeners when you ask for the current list of listeners.  (We don't use 
an iterator, but rather a method that returns an array of listeners, for 
thread safety reasons.)


Jean-Francois Poilpret wrote:

>To Howard:
>During the night (French people say that the "night gives good advice";-)),
>I thought of a quite easy workaround, that can be done at the event
>supplying service level: just use a weak reference to the listeners
>of a strong one), I think that should do the trick.
>Maybe it would even be possible to write a general "WeakEventListeners"
>class to manage all that for the event supplier:
>- when addListener, is called generate a weak reference to the added
>listener and store it in the list
>- create a specific Iterator for WeakEventListeners that would skip the
>that have become weak-reachable (and remove these from its list at the same

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message