-
1. Re: object pooling detrimental to performance
marc.fleury Feb 5, 2004 2:00 PM (in response to bill.burke)wow, quite interesting.
-
2. Re: object pooling detrimental to performance
rythos Feb 5, 2004 3:01 PM (in response to bill.burke)The intention of this code is to reuse MethodInvocation objects? Is it that costly to build them normally?
-
3. Re: object pooling detrimental to performance
bill.burke Feb 5, 2004 10:53 PM (in response to bill.burke)It is not costly to build Invocation objects (field, method, caller, etc...) as it is only a bunch of field sets.
-
4. Re: object pooling detrimental to performance
rythos Feb 5, 2004 11:29 PM (in response to bill.burke)I thought object pooling was a good idea when creating the object was costly? If creating MethodInvocations isn't a performance hit, why were you trying to pool them?
-
5. Re: object pooling detrimental to performance
marc.fleury Feb 6, 2004 8:47 AM (in response to bill.burke)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 -
6. Re: object pooling detrimental to performance
adrian.brock Feb 6, 2004 9:30 AM (in response to bill.burke)I would say that this is because the MethodInvocations aren't hard referenced
for 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 objects
need 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 objects
correctly.
FYI: I recently got rid of the object pooling in jbossmq. Not only was it
unnecessary, it made the implementation more brittle.
The message cache had to be very careful about when and what message
object it was reusing. Very error prone for any developers who weren't aware of the
pooling semantics.
Like the poster said above, you only need pool when there are significant resources
like threads or jdbc connections that make constructing the object slow.
Regards,
Adrian -
7. Re: object pooling detrimental to performance
marc.fleury Feb 6, 2004 12:27 PM (in response to bill.burke)tell bill and I about "brittleness" of pools.
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? -
8. Re: object pooling detrimental to performance
rythos Feb 11, 2004 11:39 PM (in response to bill.burke)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.
Article URL:
http://www.fawcette.com/javapro/2002_10/magazine/columns/proshop/default.aspx -
9. Re: object pooling detrimental to performance
bill.burke Feb 12, 2004 6:44 AM (in response to bill.burke)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
-
10. Re: object pooling detrimental to performance
marc.fleury Feb 12, 2004 8:08 AM (in response to bill.burke)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
-
11. Re: object pooling detrimental to performance
bill.burke Feb 12, 2004 8:36 AM (in response to bill.burke)That's not the way JBoss AOP works. There will be no problem with HotSpot as you describe.
-
12. Re: object pooling detrimental to performance
marc.fleury Feb 12, 2004 10:37 AM (in response to bill.burke)what part of JBossAOP doesn't work like what I said, explain that to me, you mean there is no advisable interface? we certainly show it in slides.
Essentially the method stack isn't set in time and therefore optimizations would be thrown off... what are you talking about? -
13. Re: object pooling detrimental to performance
bill.burke Feb 18, 2004 1:26 PM (in response to bill.burke)Ok, went even further and simplified...Still pooling was 15% slower.
private static final ThreadLocal pool = new ThreadLocal(); public static MethodInvocation create(Interceptor[] chain) { MethodInvocation mi = (MethodInvocation) pool.get(); if (mi == null) return new MethodInvocation(chain); mi.interceptors = chain; return mi; } public static void release(MethodInvocation mi) { mi.metadata = null; mi.currentInterceptor = 0; mi.interceptors = null; mi.instanceResolver = null; mi.contextResolver = null; // field/method metadata mi.classResolver = null; // field/method metadata mi.targetObject = null; mi.arguments = null; mi.method = null; mi.actualMethod = null; pool.set(mi); }
-
14. Re: object pooling detrimental to performance
spiritualmechanic Apr 16, 2004 3:04 PM (in response to bill.burke)Very interesting.