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> 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