[infinispan-dev] ClockService

[Manik Surtani]

On 30 Jan 2013, at 08:41, Bela Ban <bban at redhat.com> wrote:

> 
> On 1/29/13 6:45 PM, Manik Surtani wrote:
>> On 29 Jan 2013, at 17:17, Bela Ban <bban at redhat.com> wrote:
>> 
>>> On 1/29/13 5:25 PM, Sanne Grinovero wrote:
>>>> Glad you started work on that :)
>>>> 
>>>> Any currentTimeMillis() even today will blow away your cache line and
>>>> probably trigger a context switch.
>>> I understand the context switch (in general, it's not recommended anyway
>>> to invoke a system call in synchronized code), but I fail to see why
>>> this would blow the cache line. Are you referring to the cached Date
>>> value here ?
>> No, if you have a separate maint thread that updates a reusable currentTimeMillis value.
>> 
>> Do you use nanoTime() a lot then?  Because that too is inefficient (as per the Oracle blog) ...
> 
> Define inefficient !

There was once a misconception that nanoTime() was faster (by an order of magnitude) that currentTimeMillis().  And a similar misconception going the other way.  The reality, it would seem, is that they're both *fairly inefficient*, depending on OS architecture.

http://bugs.sun.com/view_bug.do?bug_id=6876279

> I'm sure we're talking about nanosec / microsec 
> ranges here, so 3% faster won't cut it for me. If you contrast that to 
> my current work, where I try to deliver a batch of N messages and 
> therefore can skip N-1 lock acquitions/releases for M protocols, then 
> the latter wins…

Right, I'm not entirely sure it is a hotspot for optimisation though.  I'm going by some research that Sanne did and I'm doing a bit more homework around that.

> I still think a clock service is interesting, but for different reasons. 
> As Sanne mentioned in Palma, it would be interesting to 'control' time, 
> e.g. deliver 2 messages at the same time, or even go backwards in time. 
> In the case of JGroups, we could use a clock service to screw up message 
> reception (e.g. in testing) and therefore to test the correctness of 
> some protocols.

Right, but for me that would be an additional benefit and I would de-prioritise if that was all I was getting from it.  If it is even a moderate performance boost though, say over 3% overall for such a small/simple change, then I'd do it.

- M

> 
> -- 
> Bela Ban, JGroups lead (http://www.jgroups.org)
> 
> _______________________________________________
> 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