Stolen: Re: [concurrency-interest] LongAdder (was: StripedAdder) and LongAdderTable

[William Louth (JINSPIRED.COM)]

Hi John,

In my blog entry this week I will present our current offering and its 
performance characteristics. But this is not driven exclusively by 
performance though it is a big factor. I want to make it extremely easy 
for counters (longs which cannot be decremented only incremented) to be 
added into code without too much mental & maintenance effort on the 
developer such as needing to create a field or a class holding fields 
representing counter names(paces) used as indices.

Incrementing a counter should be as easy as listing it on a line of code 
though we should also support value specific increments. Maybe this 
would be a whole lot easier with first class DSL support and later the 
JVM evolving to having some specific DSL awareness in its optimization 
routines if the context cannot be easily determined via the existing 
instruction execution mechanics.

With this proposal I am hoping that we can eliminate much of the 
logging/jmx abuses that exist today but at the same time provide a means 
for communication to flow upwards from callers without have to abuse 
return values (pairs, tuples,....). A caller could simply make a 
savepoint and then generate a changeset and see the effects (events) as 
a result of its execution and calling similar to what we offer at the 
metering level which includes both activities and meters (mapped to 
counters).

http://opencore.jinspired.com/?page_id=3553#p23

http://williamlouth.wordpress.com/2010/01/05/user-level-metering-with-savepoints-changesets/

I also see this proposal as a means for the JVM to convey provide more 
contextual runtime diagnostics (case-and-effect rather than metric 
causality) and I think it would be a much better option for dynamic 
languages to expose runtime observation rather than having them to be in 
someway retrofit to support something akin to JVMTI. For example JRuby 
could have counters named (j)ruby.object.alloc, (j)ruby.call.count,.... 
which would then be visible to Java callers (from a calling thread 
specific).

William

On 02/08/2011 00:06, John Rose wrote:
> On Aug 1, 2011, at 7:14 AM, Rémi Forax wrote:
>
>> Basically, this kind of counter already exist in the VM,
>> is there a way to bubble them up in Java ?
> William and I talked about this a little at the Summit, too.
>
> First, a caveat:  It's interesting and useful to start with pseduocode sketches of the desired functionality, along the lines of a new intrinsic "thread local long" data type in the Java language and bytecodes.  But, it is extremely rare that this turns out to be the right answer.  New bytecodes are very expensive, compared to new APIs.  All less-expensive options have to be exhausted first.
>
> The right first answer is to create a suitable Java API (usually a class), and then see how to support it in the JVM with suitable optimizations.
>
> For example, a Java ThreadLocal.get performs about the same underlying operations as a C pthread_getspecific.  When TL.get was first written, microbenchmarks showed that it was much slower than the C equivalent, but it was relatively simple to optimize the relevant code paths (especially Thread.currentThread) in the JVM.
>
> In the case of thread-local counters, an abstraction like ThreadLocal is almost certainly the right answer.  In fact, ThreadLocal<long[]>  is the first thing to try.  If that cannot be optimized enough, then we can look into further options.  Note that "cannot be optimized enough" applies only after a round of compiler work.  A failing microbenchmark is not even close to due diligence on this point!
>
> Since we don't have reified generics, ThreadLocal<long>  is not available; wish it were.  Other starting points could be ThreadLocalLong or ThreadLocalLongArray, with a suitably optimized underlying mechanism that stores exactly one long[] reference in each Thread.
>
> But ThreadLocal<long[]>  is the first thing to investigate.
>
> -- John
>