Review request: JDK-8014394 (fs) WatchService failing when watching \\server\$d

[Alexey Utkin]

On 5/23/2013 2:26 PM, Alan Bateman wrote:
> On 23/05/2013 10:34, Alexey Utkin wrote:
>> Hi Alan,
>>
>> The era of 32 is over in Apple world. Seems that is the time 
>> switching to x64 everywhere. "640K ought to be enough for anybody ".  
>> The problem is in program up-time.  If we are discussing about GUI 
>> application, 0xFFFFFFFF is infinity. But from a service point of view 
>> it is not so clear. (Webkit source-save server is a good example, 
>> but, yes, it isn't on Windows.)
>>
>> I rollback the changes in WindowsWatchService to avoid the blot.
>>
>> Regards,
>> -uta
> Do you have a pointer to the new webrev? Note that this is a 32-bit 
> vs. 64-bit issue, it's just that we are only using a small number of 
> keys at a time (and so don't need a long).
Each event increments the counter. If you are looking for stable and 
fast changing branches you have a chance of collision on overflow. The 
key for stable folder does not change, but new keys run up very fast.

If you like to decrease the footprint, I cannot understand why we are 
not using [jobject]  of [WindowsWatchKey] instance as a completion key. 
It was the main reason why MS extended the completion key to a pointer 
size. That is easy, safe and fast. Do you like to see this refactoring?

New webrev:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8014394/webrev.01/

-uta