Hi David, I'm looking forward to test your improvements using the dependencymanager benchmark tool ([1]).
[1] http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.benchmark/ /Pierre On Wed, May 13, 2015 at 3:02 PM, David Bosschaert < david.bosscha...@gmail.com> wrote: > I have implemented the performance improvements that I was thinking of > using Java 5 concurrency tools, they can be viewed at [1]. > > I wrote a little performance test suite [2] that tests multithreaded > service registry performance (10 threads) from single / multiple > bundles with either singleton services and Prototype Service Factory > services and the results are quite impressive. I'm getting performance > improvements compared to the current trunk from 8 times better than > the original (800%) to more than 30 times better (3000%). > > Carsten has already reviewed the code (thanks Carsten!) and I'm > planning to commit it to Felix tomorrow if nobody objects. > > Cheers, > > David > > [1] > https://github.com/bosschaert/felix/commit/e6a1b06c6e66d9c98e6d81b91ef7003c8e725450 > [2] > https://github.com/bosschaert/coderthoughts/tree/master/service-registry-perftest/srperf > > On 23 March 2015 at 15:39, Richard S. Hall <he...@ungoverned.org> wrote: > > On 3/23/15 10:17 , David Bosschaert wrote: > >> > >> On 23 March 2015 at 13:39, Richard S. Hall <he...@ungoverned.org> > wrote: > >>> > >>> On 3/23/15 03:55 , Guillaume Nodet wrote: > >>>> > >>>> There's a call to interrupt() in Felix#acquireBundleLock(), not sure > if > >>>> it > >>>> can be the culprit though. > >>>> Interrupts could also be caused by a bundle being shutdown while one > of > >>>> its > >>>> thread is waiting for a service, which should is a valid use case > imho. > >>>> Anyway, I think sanely reacting to a thread being interrupted would be > >>>> good. > >>> > >>> > >>> Yes, threads can be interrupted if they are holding a bundle lock and > the > >>> global lock holder needs the bundle lock. > >>> > >>> I admit that I do not recall why we ignore the interrupt here, but > didn't > >>> we > >>> implement service lookup so that a bundle lock wasn't necessary? I > >>> thought > >>> we just checked for the validity of the bundle context before returning > >>> or > >>> something. Perhaps we felt there was no reason to be interrupted in > that > >>> case. I really don't know. > >> > >> I think that the Service Registry could be rewritten to be completely > >> free of synchronized blocks using the Java 5 concurrency libraries, > > > > > > Well, that just moves the sync blocks to the library, but yeah sure. > > > >> which I think would really be a better approach. There is too much > >> locking going on in the current SR implementation IMHO. > > > > > > I don't really think there is too much, but it is complicated. > > Unfortunately, it is complicated to make sure that locks aren't held > while > > do service lookups and this is complicated because you can run into > cycles, > > etc. > > > > But feel free to try to simplify it. > > > >> > >> This brings the question: can we move to Java 5 (or Java 6) for the > >> Framework codebase? AFAIK we're currently still JDK 1.4 compatible but > >> I would be surprised if there is anyone who still needs a JDK that > >> went end-of-life 7 years ago. > > > > > > At this point, it doesn't really matter to me. > > > > -> richard > > > >> > >> Best regards, > >> > >> David > > > > >
