Incorrect validation of DST in java.util.SimpleTimeZone

[Peter Levart]

Hi Venkat,

On 11/10/17 13:07, 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.

Unfortunately, the SimpleTimeZone.invalidateCache() is also 
synchronized. So of the same cost, and it may inhibit JIT optimization.

Perhaps it would be best to synchronize cloning and then arrange the 
ZoneId.systemDefault() codepath to not involve cloning. I refrained from 
doing that in a patch for:

https://bugs.openjdk.java.net/browse/JDK-8074002

simply because it was easier and benchmarks showed that cloning is 
optimized away. But now we should reconsider that and use 
TimeZone.getDefaultRef() from the ZoneId.systemDefault() (introducing 
JavaUtilAccess into SharedSecrets mechanism)...


Regards, Peter