[concurrency-interest] Fork/Join traces: instrumentation and rendering
nathan.reynolds at oracle.com
Mon Jun 25 12:24:59 EDT 2012
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
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.
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | 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?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest