🚀 go-pugleaf

Gerry Mantha wrote:

> Hi William, check this out:
>
> http://www.javaworld.com/javaworld/jw-06-1998/jw-06-object-pool.html
>
> Here you should find all you need to get started.  This one's a very popular
> way of re-using objects in Java.  Reusing objects is also great for
> increasing performance!

There are some interesting ideas there and I'm already doing something similar
-- what I was hoping for was a discussion on better ways of doing it.  Some
items that come to mind about the above article:

  1. Until JavaSoft fixes the heap compaction problem, I would not expire
objects if the program is to be running 24x7. Expiring objects would mean memory
used by those objects won't be accessible until the JVM was reset.

  2. I'd make the "recycle bin" static so all similar objects in a JVM grabs
from the same pool.

  3. I'd make it an interface so you don't have to inherit directly from
ObjectPool.

The complications come in #3.  The obvious solution would be to force all
classes implementing the ObjectPool interface to handle all the work of creating
and managing a storage structure. I just don't like how much "copy&paste" coding
this requires -- this is NOT an object-oriented solution as making basic changes
in the ObjectPool process would require a ton of work.

Hence, my preference is overwhelmingly to have ObjectPool handle all the work.
I have a few thoughts on this matter.  First, using a single "simple" storage
structure would not work out very well.  You would have to scan through every
object checking to see whether the type matches so performance would go to hell.

Creating a new storage structure for each class implementing this interface is
the way to go.  I have a few ideas that revolve around calculating a
"fingerprint" for a class.  With this fingerprint, you could easily use it as an
index in a hastable whose items would point to a vector that stores recycle
objects.  How to calculate fingerprints is where I'm open to suggestions.

On another tangent, I've also been thinking about the concept of sharing live
objects.  Obviously, you can explicitly create code to do so -- what I would
like is the ability for completely independent code to use objects (with
unchangeable data values of course) concurrently.  Again, I'm thinking about
fingerprints -- not only class fingerprints but fingerprints for the data
values.