Preliminary review: Adding tracing of I/O calls

Remi Forax forax at univ-mlv.fr
Fri Nov 2 21:03:06 UTC 2012


On 11/02/2012 09:49 PM, Staffan Larsen wrote:
> Thanks, Jim. I'll come back with micro-benchmark numbers.
>
> /Staffan

I think this code is a good candidate for the almost final design pattern :)
http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-almost-static-final-field

Basically you want a volatile value that becomes final so it can be 
optimized by the VM.

cheers,
Rémi

>
> On 2 nov 2012, at 21:27, Jim Gish <jim.gish at 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.gish at oracle.com
>>




More information about the core-libs-dev mailing list