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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
