[infinispan-dev] ClockService

[Manik Surtani]

Interesting; looking at the code a bit more, I don't think this offers any improvements except in the case where expiry is set.  Granted, this is a useful thing to have at that point, but I'm not entirely sure whether it will affect the majority of users.

Anyway, to measure any benefit, I'm also going to have to enhance RadarGun to (optionally) set expiry information on data stored.

- M


On 29 Jan 2013, at 16:25, Sanne Grinovero <sanne at infinispan.org> wrote:

> 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
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid