[concurrency-interest] ThreadLocal vs ProcessorLocal

Nathan Reynolds nathan.reynolds at oracle.com
Thu Oct 18 12:00:42 EDT 2012


GC typically has pauses in the millisecond range.  Couldn't some of 
these outliers be due to GC? I wouldn't claim that all of them are due 
to GC since you have negative milliseconds.

I have seen the same problem in C++ programs as well (no GC).  We 
figured out that TSC wasn't synced or running at a constant rate. Once 
the processor and OS were enhanced to resolve this, the problem went away.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 10/18/2012 7:16 AM, Jacy Odin Grannis wrote:
> In our case, we knew that the operations we were measuring weren't
> taking hundreds of milliseconds (because the number of operations
> completed in a given time frame precluded that being the case).  And
> we also knew, with even more certainty, that the operations weren't
> taking NEGATIVE hundreds of milliseconds to complete, because we were
> unfortunately not clever enough to create systems that would do that.
> Given that we expected values to be in the microsecond range, and we
> had counts which backed that up, it was pretty easy to discount values
> which were clearly out of range.  Although when we first encountered
> the issue, we checked things by simply running a set of threads
> getting nanoTime values and noting when the value would suddenly have
> a large difference from the previous value, and log those values.  We
> noted that the values logged varied significantly from one thread to
> the other, and that a given thread would at times start reporting
> values which matched up with values which had been reported by a
> different thread (i.e. b/c it had been migrated to the core that other
> thread had been running on).  We were a bit surprised at how often
> even hot threads would migrate.  As far as context switches...yes,
> those could be a confounder.  In our case, we knew what the system was
> doing very well, and had a very limited number of active threads which
> did not exceed our core count, and, as I mentioned, given that we'd
> get elapsed time values occasionally which were +/- hundreds of millis
> despite simple counts which would indicate that was impossible, well,
> eliminating context switches as our issue was not too difficult.
> However, as a general rule, no, you can't reject outliers out-of-hand,
> you have to do some digging.
>
> jacy
>
> On Thu, Oct 18, 2012 at 9:00 AM, oleksandr otenko
> <oleksandr.otenko at oracle.com> wrote:
>> How do you differentiate wildly different value on the same CPU after a
>> context switch and a wildly different value on another CPU after a context
>> switch?
>>
>> Alex
>>
>>
>> On 17/10/2012 22:55, Jacy Odin Grannis wrote:
>>
>> Yes, definitely.  I've seen this happen.  One easy way you can see
>> this is System.nanoTime will suddenly start returning wildly different
>> values.  nanoTime is only consistent on a single processor, it can
>> vary widely between processors (at least on Linux).
>>
>> I think what's really needed is a set of language level constructs for
>> really addressing the problem.  I know there are experimental projects
>> looking to do that (
>> https://wiki.rice.edu/confluence/display/HABANERO/Habanero+Multicore+Software+Research+Project
>> ).  I am not sure to what extent it would be possible to build support
>> for the various constructs in the JVM; and then aside from that, how
>> you would add language support is another matter.
>>
>> Jacy
>>
>> On Wed, Oct 17, 2012 at 4:30 PM, Dr Heinz M. Kabutz
>> <heinz at javaspecialists.eu> wrote:
>>
>> [newbie question]
>>      Is it possible for a thread to ever be moved between processors, if for
>> example the is an idle processor and another that is really busy?  If not,
>> then load balancing could be problematic.  If yes, then this means that we
>> need to take this into consideration and not build static structures based
>> on the value of which processor the thread is currently running on.
>>
>> Again, if no, then what is the guarantee that it won't be available on some
>> VMs or some hardware architectures or operating systems?
>> [/newbie question]
>>
>> Regards
>>
>> Heinz
>> --
>> Dr Heinz M. Kabutz (PhD CompSci)
>> Author of "The Java(tm) Specialists' Newsletter"
>> Sun Java Champion
>> IEEE Certified Software Development Professional
>> http://www.javaspecialists.eu
>> Tel: +30 69 75 595 262
>> Skype: kabutz
>>
>>
>>
>> On 10/17/12 11:05 AM, Romain Colle wrote:
>>
>> On Wed, Oct 17, 2012 at 9:15 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
>>
>> SOT, right now we are using CPUID for a number of reasons. Very easy to
>> get to on Linux as we can do this in pure Java. However other platforms
>> require C++/assembler so having <gulp> an unsafe operation in the JVM would
>> be a win from my POV.
>>
>> I strongly second that. It is next to impossible to implement most
>> NUMA-aware algorithms without knowing on which NUMA node the current thread
>> is running.
>> Having this information available as a Java class (in Thread, Unsafe, ...)
>> would be a huge win for people like us that need NUMA-aware behavior.
>>
>> Cheers,
>>
>> --
>> Romain Colle
>> R&D Project Manager
>> QuartetFS
>> 2 rue Jean Lantier, 75001 Paris, France
>> http://www.quartetfs.com
>>
>> ________________________________
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121018/fe93d3b6/attachment.html>


More information about the Concurrency-interest mailing list