> It certainly wouldn't be easy to do ... but it sure would it be nice :)
I meant "difficult" as in "practically impossible" :) But then so are these -- http://js1k.com/ >> There's been some talk about tools to detect data races at the hotspot Found it -- see this thread: http://cs.oswego.edu/pipermail/concurrency-interest/2011-September/008205.html The tool I briefly looked at was this one: http://babelfish.arc.nasa.gov/trac/jpf > Or, even, just a way to record and then visualize what the thread > scheduling had been for a given test failure. In this case I could > have easily seen that a merge had completed before the NRT reader was > pulled (which is... unusual). This is in fact relatively easy if we allowed a jenkins run with some minor boot classpath adjustments overriding Thread's init/exit methods and logging timings from there. Obviously it'd have to be bound to a particular jvm version/ distribution but it can be done. Bytecode instrumentation would be a nicer alternative here but I'm not sure how deep it can go in terms of precedence (it'd probably need to be a native agent and this seems like an overkill). I also think (didn't check) YourKit's profiler has a thread schedule visualizer but this adds additional overhead and requires a gui (or remoting). Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
