On 25/06/12 17:24, Nathan Reynolds wrote:

 Static final booleans initialized at runtime will *hopefully* cause JIT optimization to throw out the check and dead code.  I haven't checked this latter point.

They do in my experience. My tracing code relies on it to give zero cost when disabled. I think this also applies to assertions.

Mark Thornton

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Hi Nathan,

I would actually like to see instrumentation being added into many of the core libraries but not in the way proposed here because I agree with you that this is best left to method level (typically timing/tracing/metering based) agents based on BCI (AspectJ, BCEL, ASM,...). The type of instrumentation I would like to see added would not be possible with such approaches - at least not in a maintainable fashion. The approach I have in mind will allow library developers to expose (and control exposure of) underlying signals which (may or may not be) driving factors in the performance of the library in servicing a particular request/call. I have actually created this approach for extreme low latency environments in which timing is not reasonable (sub microsecond) and used it in our own software to allow the software to observe its own behavior, learn & understood what signals drive its performance (throughput or latency) under the conditions (not under its control) and then to adapt. I had hoped to present the approach at the JVM lang summit this year but unfortunately I am traveling (around Asia) at that time. We plan to release it, Signals, into the public in August but hopefully next week or the week after I can get out a blog which introduces some of the concepts and the reasoning behind it from our experience building a lmetering engine that measures performance of low latency (though variable depending on context/state) Java libraries.

Getting back on track a little the reason for my response is that I do believe it is time to revisit the approach to serviceability (in particular observation) in the runtime and to (re)consider/focus runtime adaption (in particular optimization) above the hotspot engine itself. I would like to see the JVM & JDK enhanced to make this far easier and standardized across libraries, frameworks and stacks. But to do this in a way that minimizes risks due to changes we might very well need some special help from the lang and JVM itself. Which means the JVM/JDK team(s) need to be open to instrumentation in a manual form though probably not how they are accustomed to seeing such.

Today a return (or exception) gives a result of an interaction. Signals will look to expose (though to some degree under control of library developer) what actually transpired in doing so which might very well involve multiple thread execution contexts. Think of it a bit like someone not just asking for the work they gave you to do but also asking how did it go in delivering the work for the purpose of improvement (which can take many forms).

William

Code weaving is a good route.  BTrace, AspectJ or other tools (?) will make this simple.  Static and member empty methods will be inlined by JIT optimization and hence no instructions will be added to the optimized code.  These methods will impact interpreted code and hence impact start up and warm up.  These methods will add a bit more memory usage since there are additional bytecodes and metadata about the methods.  I kind of doubt these latter 2 points will have any significant impact.

Static final booleans initialized to a constant will cause javac to discard the check and dead code.  No interpreter impact and no bytecode impact.  Static final booleans initialized at runtime will *hopefully* cause JIT optimization to throw out the check and dead code.  I haven't checked this latter point.

Nathan Reynolds | Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering | Server Technology

On 6/17/2012 1:52 PM, Aleksey Shipilev wrote:

On 06/18/2012 12:39 AM, Doug Lea wrote:

I/We don't see a way to do it with zero guaranteed impact vs non-instrumented code. But after giving fjp-trace some time to settle in, we'll find some reasonable way to semi-integrate to make it easier to use for diagnostics.

Sure, let it brew. In the mean time, let's consider more light-weight ways to hook up the instrumentation code. I would go the code weaving route, but that will require specific junction points within FJP to weave to. Would calling dummy (static?) FJP methods in the places where registerEvent() is called in current code work as zero-impact marker? (Now the crazy talk). Other options are: - protecting instrumentation calls with asserts and weave them into existence when tracing is enabled? (Not really different from in-place static final boolean check). - local variables with special names get written with the event; hoping smart JIT will otherwise optimize the write away. (Is not really working for interpreter and inferior "java" VMs). - anything else? -Aleksey.

_______________________________________________ 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