Preliminary review: Adding tracing of I/O calls (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Fri Nov 2 22:21:33 UTC 2012

On 02/11/2012 18:36, Staffan Larsen wrote:

This is a preliminary review request for adding an API for tracing 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 listener and get callbacks 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/iotrace/webrev.00/ Feedback is most welcome, /Staffan Part of me is a somewhat disappointed to see hooks going into the I/O paths, but I understand why it needs to be done. I see the mails that getting some performance figures on the overhead and that would be good to have.

I think IoTrace/IoTraceListener needs to have some javadoc. I suggest this because it's impossible to implement IoTraceListener (even in the JDK) without some documentation as to how it is used. I see there is a block comment in IoTraceListener but there are other things that an implementer needs to know, particularly as to possible behavior when there is an I/O error. Looking at the usages then it looks like in *End might not be called, in other cases it can be called with 0 when there is an error.

I also see mails about IoTrace.listener needing to be volatile, that would be good to do.

I also think it would be useful to have a basic sanity test of the hooks. I realize there will be product usage elsewhere but we should have something simple in the jdk repository too.

In FileInputStream, FileOutputStream and FileChannelImpl then the comment on path is that it is null "if there is no file" but I think this should say that the stream (or parent stream in the case of a file channel) is created with a file descriptor.

In SocketChannelImpl then if the channel is configured non-blocking socketReadEnd will be called without a socketReadBegin. If this is intended then it will be something for the IoTrace/IoTraceListener javadoc.

I realize the focus is blocking I/O for now but one thing to know is that timed read operations on socket adapters (the socket obtained by calling SocketChannel's socket method) configures the socket channel to be non-blocking so this means that this I/O will not be observed by the IoTraceListener.

In both FileChannelImpl and SocketChannelImpl then normalize will now be called twice on each return status, I don't expect this will be observable from a performance perspective.

SolarisUserDefinedFileAttributeView - this is I/O on a file's extended attributes rather than its contents, it might not interesting to the IoTraceListener.

UnixChannelFactory L137, this line is getting long, might be better to go into a second line.

WindowsChannelFactory - one thing to be aware of is newFileChannel will also be called when open named streams so pathForWindows won't be the name of a file that you see on the file system. I don't know if this is interesting here or not, it should be rare.

That's all I have.

-Alan.

More information about the core-libs-dev mailing list