Did some tests in AOP framework with object pooling through a ThreadLocal. I found that it actually slowed down performance by 20%. This finalizes what I've thought all along that Object pooling is worthless and it is better to let the VM handle it.

That is kind of interesting really. People where bitching about the hit they were taking with the object creation. I find it hard to believe that in fact it is FASTER to not pool. Very interesting. I guess the limit is VM garbage collection on large system vs pooling. Meaning in the future we should think about it in the scope of scalability.

But for now people are going to bench invocations one by one so this number is better

I would say that this is because the MethodInvocations aren't hard referencedfor very long. The GC can easily dispose of short lived references.

If you try to pool them, you are making more work for the GC because the objectsneed to be continually checked.

The latest GCs do object pooling anyway for frequently used object types.Let the JIT decide what objects need to be pooled.It can will do a better job anyway - you can make mistakes by not reinitialising objectscorrectly.

FYI: I recently got rid of the object pooling in jbossmq. Not only was itunnecessary, it made the implementation more brittle.The message cache had to be very careful about when and what messageobject it was reusing. Very error prone for any developers who weren't aware of thepooling semantics.

Like the poster said above, you only need pool when there are significant resourceslike threads or jdbc connections that make constructing the object slow.

the entity pooling was A NIGHTMARE to debug back in the days. The state in them was always difficult to control, cleanup was a nightmare. WE finally decided to drop it there in favor of pools that just "preinstanciated" but when an object was done we would let it die, in short we would not use pools for "reuse" at all.

Also the VM insight you give is probably linked to generational garbage collection, obviously the VM has to work on new references but never promotes them to "long lived" so it can be pretty efficient in killing newly instanciated object that are short lived <1s like the invocation object.

So the only idea that would stand is to pre-create objects and do setters on them so it is really fast. Bill is that what you mean when you say we are already doing sets?

Read an article today on HotSpot optimization that says basically the same thing you said about object pooling. On page 6:

For example, the HotSpot development team strongly recommends that you not maintain your own object pools. Instead, you should trust the memory allocation and garbage collection system to work efficiently.

I have heard different things from different people. My thought was always that the VM was better than pooling, but I've had people argue for (and code) pooling. So I just went and found out for myself

One more thing that will throw off HotSpot is the Advisable interface since it essentially says that the profile of a method changes in time. There need to be callbacks on insertion of interceptors to retrigger compilation