On 19 nov 2012, at 10:52, Alan Bateman <alan.bate...@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
