I've committed this now in http://svn.apache.org/viewvc?view=revision&revision=1679327
Curious to see what others are measuring. My tests were focused on multiple bundles/threads obtaining the same service, as that's were I saw a bit of contention. Cheers, David On 13 May 2015 at 15:10, Pierre De Rop <pierre.de...@gmail.com> wrote: > 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 >> > >> > >>
