[infinispan-dev] ClockService

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 implem

Re: [infinispan-dev] ClockService

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

Re: [infinispan-dev] ClockService

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 als

Re: [infinispan-dev] ClockService

On 1/29/13 5:02 PM, Manik Surtani 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 co

Re: [infinispan-dev] ClockService

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 synchro

Re: [infinispan-dev] ClockService

On 29 Jan 2013, at 17:17, Bela Ban 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

Re: [infinispan-dev] ClockService

On 29 Jan 2013, at 16:25, 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. > > Having it as a service we will be able to experiment: the first thing > I'll do is replace it wit

Re: [infinispan-dev] ClockService

On 29 Jan 2013, at 17:45, Manik Surtani wrote: > > On 29 Jan 2013, at 17:17, Bela Ban 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 sw

Re: [infinispan-dev] ClockService

On 29 Jan 2013, at 18:27, Mircea Markus wrote: > I guess Bela's question was about why System. currentTimeMillis() would > trigger a context switch, I'm also curious about that one :-) On its own it doesn't. But if we have a cached clock with a scheduled thread updating that cached value per

Re: [infinispan-dev] ClockService

On 1/29/13 6:45 PM, Manik Surtani wrote: > On 29 Jan 2013, at 17:17, Bela Ban 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 under

Re: [infinispan-dev] ClockService

On 1/29/13 7:25 PM, Mircea Markus wrote: > On 29 Jan 2013, at 16:25, 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. >> >> Having it as a service we will be able to experi

Re: [infinispan-dev] ClockService

On 1/30/13 1:45 AM, Manik Surtani wrote: > > On 29 Jan 2013, at 18:27, Mircea Markus > wrote: > >> I guess Bela's question was about why System. currentTimeMillis() >> would trigger a context switch, I'm also curious about that one :-) > > On its own it doesn't. But if

Re: [infinispan-dev] ClockService

On 30 Jan 2013, at 08:41, Bela Ban wrote: > > On 1/29/13 6:45 PM, Manik Surtani wrote: >> On 29 Jan 2013, at 17:17, Bela Ban 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 l

Re: [infinispan-dev] ClockService

Manik, I think that JDK bug is pretty out-of-date, at least on Fedora. I ran the micro-benchmark in the bug (with some modifications: https://github.com/danberindei/infinispan/blob/t_time_sources_test/core/src/test/java/org/infinispan/TimeSourcesTest.java) when we had the last round of discussions

Re: [infinispan-dev] ClockService

On 30 Jan 2013, at 09:14, Dan Berindei wrote: > Manik, I think that JDK bug is pretty out-of-date, at least on Fedora. > > I ran the micro-benchmark in the bug (with some modifications: > https://github.com/danberindei/infinispan/blob/t_time_sources_test/core/src/test/java/org/infinispan/TimeS

Re: [infinispan-dev] ClockService

Seems that the bug you mention below was not deemed critical by SUN/Oracle, as it won't get fixed. Wrt JGroups use, I only call nanoTime() when I need fine grained resolution, e.g. in perf tests, or in the following places: - Timeouts waiting for results from RPCs. Here, we're usually talking s

Re: [infinispan-dev] ClockService

On Jan 29, 2013, at 6:07 PM, Manik Surtani wrote: > 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 th

Re: [infinispan-dev] ClockService

On Jan 29, 2013, at 6:45 PM, Manik Surtani wrote: > > On 29 Jan 2013, at 17:17, Bela Ban 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 contex