[9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock

[Roger Riggs]

Hi Brian,

WRT webrev.04:

FileLockTable.java: 92: to keep the methods consistent with the internal 
state, change the field "invalid" to "valid".
That will make it easier to understand and avoid various code that 
invert the meaning.

Where did the test hang when it timed out?  Since the test does not drop 
the references
to raf1, it may be that none of it is every released.

The Cleaner might be an option to do the final cleanup of Unreferenced 
FileLocks.

$.02, Roger


On 1/31/2018 10:58 AM, Brian Burkhalter wrote:
>
> On Jan 30, 2018, at 11:30 PM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>>> I don’t see how to do this. The FileLock already holds a reference 
>>> to the Channel and if the converse were to obtain there would be 
>>> circular references and things blocked from being collected.
>> I think that is the behavior you are looking for. The FileChannel 
>> keeps the FileLocks alives, the FileLocks give the FileChannel alive. 
>> If the application discards the reference to both then they will 
>> eventually be GC'ed once the entry in the SharedFileLockTable is 
>> expunged.
>
> I implemented that and the test in this webrev did not complete 
> normally but timed out.
>
> Brian