Adrian Crum wrote: > I remember when Javolution was first brought into the project. The > reason for adding it was better performance. I was new to the project at > the time, so I just assumed that was true. > > Since then I have read many books and articles on Java, and now I'm not > sure that Javolution is appropriate for this project.
I've also had doubts about FastMap(javolution). It doesn't implement ConcurrentMap; the putIfAbsent method it *does* implement is not completely defined. FastSet/FastMap don't have a defined order. It appears to be linked, when no Comparator is used, but that is not well defined. javolution itself is supposed to be defined as being more consistent in memory usage and performance. The library says these are useful when the target platform is an embedded environment. However, ofbiz is not really an embedded-type application. The extra overhead that javolution uses for maintain memory block areas makes it very hard for the jvm to do the new fancy escape analysis. Lots of places in ofbiz use FastMap/List/Set. They are not useful, however, in places that only get populated at startup, and never ever changed thereafter. I've started fixing some of these use cases as I spot them. My opinion is that javolution usage should start to be phased out. > > -Adrian > > > On 6/9/2010 1:28 PM, Adam Heath wrote: >> Adrian Crum wrote: >>> "Public service announcement: Object pooling is now a serious >>> performance loss for all but the most heavyweight of objects, and even >>> then it is tricky to get right without introducing concurrency >>> bottlenecks." >>> >>> http://www.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends >>> >> >> What's cute about this, is that that article is from *before* the >> factory stuff was added to conditions. >> >>> -Adrian >>> >>> On 6/9/2010 11:19 AM, Adam Heath wrote: >>>> Why does EntityCondition create objects from a factory? This means >>>> that any condition that needs to be created will end up storing the >>>> object into the global heap, with all the requisite locks and >>>> contention that occur from that. If a new object was just created, >>>> however, java1.6 has the ability to allocate it on the stack, when >>>> then means freeing said object is much more efficient. >>>> >>>> I'm suggesting that the global factories for conditions be removed, >>>> but the actual factory methods themselves should remain. >>>> >> >>
