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

Reply via email to