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
