On 05/30/2012 06:24 AM, Adrian Crum wrote: > I am reposting this thread with a different subject to make sure > everyone interested has a chance to comment. > > To summarize (and to make sure we are all on the same page): > > 1. Javolution was added to the project in the JDK 1.4 days. David > Jones ran some performance tests that demonstrated a performance boost > when using Javolution Fast* classes instead of java.util.* classes. > 2. Javolution acheived this performance boost by eliminating some > garbage collection. The Fast* classes use object pools - where objects > are returned to the pool when they are unused instead of being garbage > collected. > 3. JDK 1.5 introduced an improved garbage collector that eliminated > the long pauses caused by previous garbage collectors. Also, it > introduced the java.util.concurrent package - which is functionally > similar to Javolution's concurrency. When OFBiz switched to the JDK > 1.5 requirement, the need for Javolution was eliminated - but it was > kept in the project anyway. > 4. No performance tests have been executed recently to see what kind > of impact removing Javolution will have. > 5. In the attached thread I recommend removing Javolution from object > fields that are effectively static (either declared static or a field > of an object that is cached indefinitely), because the pooled object > is never returned to the pool - defeating the purpose of the library. > 6. In the attached thread Adam suggests removing Javolution entirely.
7: In JDK 1.6, escape analysis is used to figure out that some objects can be directly allocated on the stack, instead of the heap. Using pooled objects precludes this. When using EntityCondition pooled objects, where the condition will eventually be frozen and used as a key in a cache, it makes no sense really to pool it at all. When doing the actual query, escape analysis *might* detect that the condition could be allocated on the stack(it'd have to look at several deep method calls).
