On 07/02/14 15:24, Dmitry Samersoff wrote:
Staffan,

FileInputStream.java

55:  It's better to initialize path with null.

I'm afraid I disagree with this. The default value is already null, why set it to null again? I see this pattern all over the code, but it seems completely redundant to me.

-Chris.

134: It's better to assign name at one of first lines, in this case we
will be able to retrieve file name ever if open fails for some reason.
171: It's not necessary

(the same is applicable to other files)

I'm a bit scared changing signature of public methods of FileChannelImpl
but if Alan says it's OK - lets go with it.

-Dmitry


On 2014-02-07 16:07, Staffan Larsen wrote:
Instrumentation agents that want to instrument
FileInputStream/FileOutputStream to see which files are being
accessed do not currently have access to the file system path of the
stream. This is because the path is never stored in the stream class,
only the file descriptor is. (This is also true for RandomAccessFile
and FileChannel).

An agent could instrument the respective constructors to store the
path. The problem is where to store it. To add a field, the
instrumentation agent needs to change the schema of the class. This
is not possible at runtime but can be done at class-loading time.
However for a j.l.instrument agent these classes are already defined
when the agent is first called. For a native JVMTI agent the problem
becomes parsing and modifying byte codes in a native agent which is
error prone and requires a lot of code to maintain.

If instead the stream classes were modified to store a reference to
the path, it would be readily available for agents at a minimum of
cost to the libraries. This is what this patch does. FileInputStream,
FileOutputStream, RandomAccessFile and FileChannelImpl are modified
to record the path they operate on in a private field. There are no
accessors added to retrieve the path - it is purely stored for
instrumentation purposes. The path is intentionally not resolved to
be an absolute path since that would potentially add unwanted
overhead. If a stream is created from a file descriptor, no path will
be stored.

The overhead for this path will be keeping the path String alive for
a longer period of time. I hope this will not cause any problems.

A consumer of this feature will be Java Flight Recorder, but the
implementation is usable by other agents as well.

webrev: http://cr.openjdk.java.net/~sla/8033917/webrev.00/ bug:
https://bugs.openjdk.java.net/browse/JDK-8033917

Thanks, /Staffan



Reply via email to