[concurrency-interest] Fork/Join traces: instrumentation and rendering
radhakrishnan.mohan at gmail.com
Mon Jun 18 10:41:38 EDT 2012
I have used AspectJ and tried it with FJ. It works but the change to the
code after weaving aspects could introduce subtle concurrency bugs. I
thought that merging a framework written by experts and aspects written by
me is cause for trouble. The technology will work very well because I have
woven aspects into even containers like WebSphere.
My idea was to use JavaFX to show a GUI by weaving into FJ. The POC worked.
On Mon, Jun 18, 2012 at 2:22 AM, Aleksey Shipilev <
aleksey.shipilev at gmail.com> 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