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