Incorrect validation of DST in java.util.SimpleTimeZone

[Seán Coffey]

I think the OpenJDK mailing lists accept attachments if in patch format. 
If it's a simple short patch, it's acceptable to paste it into email body.

Easiest solution is to use webrev[1]. If you can't upload this to 
cr.openjdk.java.net - then one of your colleagues may be able to help.

[1] http://openjdk.java.net/guide/webrevHelp.html

Regards,
Sean.

On 10/11/17 12:18, Venkateswara R Chintala wrote:
> Looks like the patch attached earlier is not visible. As this is my 
> first contribution, please let me know how I can send the patch for 
> review.
>
>
> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>> Hi,
>>
>> In a multi-threaded environment, when java.util.SimpleTimeZone object 
>> is used to create a default timezone, there can be a race condition 
>> between the methods java.util.Timezone.getDefault() and 
>> java.util.Timezone.getDefaultRef() which can result in inconsistency 
>> of cache that is used to validate a particular time/date in DST.
>>
>> When a thread is cloning a default timezone object (SimpleTimeZone) 
>> and at the same time if a different thread modifies the time/year 
>> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
>> become inconsistent which leads to incorrect DST determination.
>>
>> We considered two approaches to fix the issue.
>>
>> 1)Synchronize access to cloning default timezone object when cache is 
>> being modified.
>>
>> 2)Invalidate the cache while returning the clone.
>>
>> We preferred the second option as synchronization is more expensive.
>>
>> We have attached the patch and jtreg testcase. Please review.
>>
>