Preliminary review: Adding tracing of I/O calls

[Jim Gish]

Hi Staffan,

This looks fine to me as well, but I had the same question as Mandy 
about performance.  Given the sensitivity to changes in I/O it would be 
good to have some micro-benchmarks here.

Thanks,
    Jim
On 11/02/2012 04:12 PM, Mandy Chung 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?
>
> 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?
>
> Do you have any performance measurement result that you can share?  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?
>
> Mandy
>
>> Feedback is most welcome,
>> /Staffan
>>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com