RFR: 8003322: Add instrumentation points for tracing of I/O calls

[Staffan Larsen]

On 19 nov 2012, at 10:52, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 15/11/2012 15:50, Staffan Larsen wrote:
>> 
>> I now have some micro-benchmark numbers on windows and linux (the solaris runs are not complete yet). While doing these runs we initially saw a regression on the file reading benchmarks. Investigation showed that the compiler was not able to inline the IoTrace.xxBegin() and IoTrace.xxEnd() methods because the IoTraceContext class in the signature had not yet been loaded. This forced me to go back to just an Object in the signatures for these methods which allowed them to be inlined and performance restored. 
>> 
> Thanks for creating a set of micro-benchmarks and reducing the concern about this instrumentation.
> 
> I guess you saw the review request from Nils where he proposed adding invasive instrumentation to Throwable.  The consensus in the replies was that bytecode instrumentation seemed more appropriate. Aside from the path field that you've added to the streams classes, is there any reason why the I/O instrumentation couldn't also be done with bytecode instrumentation?

I think you are right that bytecode instrumentation would also work. The only problem I see (apart from the path field) is the time it would take to develop such a solution. I'm not sure if that is a good enough argument for keeping the non-bytecode-instrumentation solution, though. Or if we could replace the non-bytecode-instrumentation solution with an updated bytecode instrumentation solution in a later update? Not ideal, but would allow us to complete the project on time.

Thanks,
/Staffan