Re: [infinispan-dev] ClockService

Glad you started work on that :) Any currentTimeMillis() even today will blow away your cache line and probably trigger a context switch. Having it as a service we will be able to experiment: the first thing I'll do is replace it with a NOOPService and see how much it improves.

Ideally I'd like it to have multiple methods so that different needs can hint about a different level of precision, or maybe expect an enum as parameter which represents the hint. Cheers, Sanne On 29 January 2013 16:02, Manik Surtani <msurtani(a)redhat.com&gt; wrote: > Thinking about Sanne's idea re: a clock service and not continuously relying on System.cTM, I stumbled upon this: > > https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very > > The last section re: caching is interesting. > > Having all code use a Clock.currentTimeMillis() and having an implementation that kicks off a scheduled task to update a cached value every $frequency millis (by using the System call) is probably the correct way to implement something like this, but this adds complexities/concerns: > > * CPU cache line blowing away (see article) > * Context switching > * Managing an extra service thread > * Probably an additional configuration option to configure that thread, its priority and frequency. If frequency is dropped (e.g., every second) I suppose the perf gains would be huge. > > JGroups - does JGroups make many and frequent calls to System.cTM as well? > > Cheers > Manik > -- > Manik Surtani > manik(a)jboss.org > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev