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