RFR: 8003322: Add instrumentation points for tracing of I/O calls
staffan.larsen at oracle.com
Tue Nov 13 10:16:57 UTC 2012
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).
I believe all comments from the preliminary review  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.
More information about the core-libs-dev