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

[Staffan Larsen]

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