Alleviating the need for Checkin in Object pool
Hi,
I have a rather daunting question I was hoping one of you guys can solve.
I have been trying to implement an object pool that will not require object check-in.
In other words, checked out elements, no longer strongly referenced, are somehow checked-in back into the pool without any required intervention from the client which checked them out. This behavior is required as I need to 憄lug?the pool into an existing code which creates the would-be pool elements in relatively small number of focal points in the application, but uses them within method scopes (which means I would have to modify virtually all methods in over 500 class files in order to check-in the objects at the end of each method.
So far I have been looking at any sort of interaction with the garbage collection such as the java.lang.ref
package Reference
and ReferenceQueue
classes, Proxy
classes but to no avail.
Please bear in mind that the aim of this pool is to enhance performance and not introduce new performance bottle-necks (e.g. proxy object for each of the pooled objects etc.).
I am positive I am missing something obvious and stupid but no solution comes to mind and I would appreciate any assistance.
[1265 byte] By [
sg9aeea] at [2007-11-27 1:53:33]
# 3
Hi thanks for your replies, they are appreciated.
Regarding the first one: whilst object creation is not a hindrance on performance garbage collection is and having so many dead objects lying around just triggers it more often, thus I can justify the need for such an exploit.
With regards to the second reply: I would require the opposite of your functionality --> i.e. when the object is no longer strongly referenced, it is returned to the pool automatically. I gather you probably use a Soft or Weak Reference and a ReferenceQueue and poll it in a separate thread and each popped reference removed from the ReferenceQueue you remove from your pool as you store the pool objects wrapped in the said reference. if this is indeed so, than by the time the reference is enqueued by the GC, it will no longer contain the reference to the pool object I need. If not than this is exactly what I need, thanks in advance
# 5
lol,
I have to concur, it is just that, breaking the code and causing more test cycles in the sunny day scenario and regression in the rainy day one.
Alas, I had been tasked with identifying performance bottlenecks and solving them and GC is a major one in this case. Moreover the application抯 footprint heretically fluctuates which is always a good sign of change to come...
# 6
> Hi thanks for your replies, they are appreciated.
> Regarding the first one: whilst object creation is
> not a hindrance on performance garbage collection is
> and having so many dead objects lying around just
> triggers it more often, thus I can justify the need
> for such an exploit.
> With regards to the second reply: I would require
> the opposite of your functionality --> i.e. when the
> object is no longer strongly referenced, it is
> returned to the pool automatically. I gather you
> probably use a Soft or Weak Reference and a
> ReferenceQueue and poll it in a separate thread and
> each popped reference removed from the ReferenceQueue
> you remove from your pool as you store the pool
> objects wrapped in the said reference. if this is
> indeed so, than by the time the reference is enqueued
> by the GC, it will no longer contain the reference to
> the pool object I need. If not than this is exactly
> what I need, thanks in advance
This is pretty much how it works. Slightly more complicated than it might appear at first glance.
If you want to 'return' an object all you need to do is wrap it and pass out the wrapper. Never let any object get ahold of the encapsulated object. Hold the weak reference to the wrapper. When the wrapper is collected you know that object can be returned to the pool.
You want to be sure to use weak reference and not soft reference.
