Thanks, Jim. I'll come back with micro-benchmark numbers. /Staffan
On 2 nov 2012, at 21:27, Jim Gish <jim.g...@oracle.com> wrote: > 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.g...@oracle.com >
