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@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@jboss.org

twitter.com/maniksurtani

Platform Architect, JBoss Data Grid

http://red.ht/data-grid

_______________________________________________

infinispan-dev mailing list

infinispan-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev