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 <[email protected]> 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 > [email protected] > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
