It would be interesting to identify the characteristics of the JPA ConcurrentHashMap implementation that make it preferable to the JDK one, so that possibly the JDK one can be improved.
> -----Original Message----- > From: Jeremy Bauer (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 18 June 2008 4:52 a.m. > To: [email protected] > Subject: [jira] Updated: (OPENJPA-637) Significant performance degradation > when data cache is enabled > > > [ https://issues.apache.org/jira/browse/OPENJPA- > 637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Jeremy Bauer updated OPENJPA-637: > --------------------------------- > > Attachment: OPENJPA-637.patch > > Attaching a patch for 1.2.0 which adds-back and utilizes the OpenJPA > ConcurrentHashMap implementation. Based on benchmark results and > additional testing with the Java 5-based implementation, use of the > OpenJPA implementation appears to be the best course of action. Comments, > please. > > > Significant performance degradation when data cache is enabled > > -------------------------------------------------------------- > > > > Key: OPENJPA-637 > > URL: https://issues.apache.org/jira/browse/OPENJPA-637 > > Project: OpenJPA > > Issue Type: Bug > > Components: datacache, lib > > Affects Versions: 1.2.0 > > Reporter: Jeremy Bauer > > Attachments: OPENJPA-637.patch > > > > > > Performance testing is showing a severe data cache performance > degradation when moving from 1.0.x OpenJPA code to 1.2.0 level code. > Profiling showed the problem to be in the new random eviction scheme which > runs when the cache reaches its maximum number of entries. This code was > changed significantly when OpenJPA moved to Java 5 > java.util.concurrent.ConcurrentHashMap and away from the OpenJPA > implementation of ConcurrentHashMap. A macro-benchmark showed a 20% > performance degradation from base 1.2.0 code when the cache reaches its > maximum size; prompting eviction in order to add new cache entries. > > I've found that the new random eviction code appears to be improved in > the very recent 666903 commit, but data cache performance remains > considerably slower than the 1.0.x implementation. Profiles with the > 666903 changes show test threads to be waiting on the reentrant write lock > in the CacheMap wrapper (which now wrappers a max size capable, null > handling, subclass of java.util.concurrent.ConcurrentHashMap). > Investigation is underway to determine whether the write lock is necessary > (ie. can java.util.conncurrentConcurrentHashMap manage the cache without > the need for external locking) and/or if changes could be made which would > result in a significant reduction in contention for the lock. Any > thoughts/ideas on that would be extremely helpful. > > Performance tests run with the 1.2.0 code base, using the OpenJPA > version of ConcurrentHashMap (instead of the Java 5 > java.util.concurrent.ConcurrentHashMap-based implementation) have shown > that performance of the data cache is significantly better when the > legacy OpenJPA implementation is used. Based on the results, it appears > that OpenJPA should be using the the legacy ConcurrentHashMap instead of > the Java 5-based implementation -- or the new Java 5-based implementation > needs to be improved considerably in order to perform as well as 1.0.x. > > I am opening this as a 1.2.0 issue, although it very likely affects > 1.1.x as well. Testing has not been performed on 1.1.x to confirm the > problem exists on that release. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online.
