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

Jim Gish jim.gish at oracle.com
Fri Nov 2 20:27:10 UTC 2012

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

More information about the core-libs-dev mailing list