Preliminary review: Adding tracing of I/O calls

[Staffan Larsen]

On 2 nov 2012, at 21:12, Mandy Chung <mandy.chung at oracle.com> wrote:

> Hi Staffan,
> 
> On 11/2/2012 11:36 AM, 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/
> 
> This looks okay to me.
> 
> Minor comments:
> sun/misc/IoTrace.java L36: should it be volatile in case another thread is setting to another listener?

Yes, that could be a good idea.

> The *Begin() methods return a "handle" that will be passed to the *End() methods.  Have you considered to define a type for it rather than Object?

Something like an empty interface, just to signal the intent?

> Do you have any performance measurement result that you can share?  

I don't yet have any specific numbers - I'll try to get some. The testing I have done indicates that the overhead is negligible. But it would be good to confirm this.

> As for the unit tests, I know you have tests written for the feature that implements the listeners.  I wonder if it's worth adding some sanity tests along with this change?

Yes, that is probably a good addition, too.

Thanks!
/Staffan

> 
> Mandy
> 
>> Feedback is most welcome,
>> /Staffan
>>