🚀 go-pugleaf

Hello again William,


William Yu wrote in message <35A03942.7B8BBB35@Bigfoot.com>...

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


So, if your sure cleanup doesn't occur, don't expire them.


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


Don't quite get you here....


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


What's wrong with inheriting from ObjectPool?  Isn't that what abstract
classes are for?  The common work is in the abstract class... Perhaps I'm
missing your point here too.

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


I don't copy&paste either, nor do I let my developers do it.  There are two
choices... inheritance or delegation.  If your really put off by inheritance
and want weaker coupling between your classes, use delegation patterns.

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


I'm missing you here too I think.  First, with an object pool you don't scan
or iterate looking for type matches.  There exists a separate object pool
for each type.  Any iteration is done for validation purposes (for
connection reuse and such only).


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


If you require speed, and you know your JVM will run out of memory, I'd
suggest avoiding vectors like the plague.  You don't require a fingerprint.
Put a wrapper around each class you wish to recycle, and have it do the
instanciation.  Or to save more memory, have the client code access the
object pool indirectly through a call to a static class with a static final
int representing the class type you require from the object pool.

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


Sharing live objects is central to any good OO design.  Avoid inheritance,
delegate like crazy, param everything, plug&play!  Forget about
implementation, and concentrate on the interface, use UML... but most of
all, have fun!

Gerry