This is a request for review for adding tracing to I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a callback for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available).
Webrev: http://cr.openjdk.java.net/~sla/8003322/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 I believe all comments from the preliminary review [1] have been addressed. In particular: - To minimize the overhead, the instrumentation calls now end up in _empty_ static methods in the IoTrace class. To enable instrumentation this class has to be redefined by an agent. To see how this work have a look at the tests. With this new design, I have not been able to measure any overhead of the disabled instrumentation. - Tests have been added that do basic sanity testing of the instrumentation points and the data in the instrumentation. - Javadoc has been added to the IoTrace class and the instrumentation has been updated to conform to this documentation (especially in the face of exceptions). - The previous Object "handles" are now called "contexts" and have a marker interface called IoTraceContext. - SocketAdapter has been instrumented. There is one remaining issue: IoTrace and IoTraceContext are now in sun.misc, but concerns where raised that this would be a problem with jigsaw. Suggestions are welcome if this is still a problem. Thanks, /Staffan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012066.html