Code review request for 7049774

[Seán Coffey]

On 09/06/2011 17:05, Chris Hegarty wrote:
> I looks like this change may break the UID spec.
>
> "# time, a long equal to a time (as returned by 
> System.currentTimeMillis()) at which the VM that this UID was 
> generated in was alive, or zero for a well-known UID  "
>
> 'time' may no longer be equal to currentTimeMillis.
currentTimeMillis is only called after the 2^16 ids have be used/exhausted.
time refers to time at when the VM was alive. We're still honouring this.

The fix addresses a corner case where system clock may have gone backwards.
At this stage the spec could become vague since it assumes "system clock 
is never set backward"

This is making best case solution to such an issue.
regards,
Sean.
>
> It looks like count is incremented for every UID created. I wonder if 
> it may only be necessary to increment count if there is another UID 
> created with the same time. This would allow a much larger number of 
> UID's to be created before encountering the issue you are seeing?
>
> I'm guess that this change is actually targeted to jdk8, rather than 
> the 'compare against' gate shown in the webrev.
>
> -Chris.
>
> On 06/ 9/11 04:26 PM, Seán Coffey wrote:
>> 7049774 : UID construction appears to hang if time changed backwards
>>
>> I'm looking for code review of above reported issue. If system clock 
>> goes
>> backwards on rmi server with active clients and 64k UID boundary is hit,
>> the server will wait until system time progresses past the time at which
>> UID class
>> was instantiated.
>>
>> Fix is to not to use earlier times for such corner cases.
>>
>> bug ID should become public on bugs.sun.com over coming day.
>>
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7049774.0/
>>
>> Regards,
>> Sean.