[concurrency-interest] Fork/Join traces: instrumentation and rendering

Aleksey Shipilev aleksey.shipilev at gmail.com
Sun Jun 17 16:52:46 EDT 2012

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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120618/cafda3c0/attachment.bin>

More information about the Concurrency-interest mailing list