[infinispan-dev] ClockService

[Sanne Grinovero]

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