RFR 8025971 and 8026197

[roger riggs]

Hi Sherman,

On 10/15/2013 4:23 PM, Xueming Shen wrote:
> On 10/15/2013 01:03 PM, roger riggs wrote:
>> Hi Sherman,
>>
>> I can't help but notice that the tzdb.dat file is read using a 
>> doPrivilege block in
>> ZoneInfoFile.java but not in TzdbZoneRulesProvider.java.
>>
>
> TzdbZoneRulesProvider is package private. It is initialized inside the 
> doPrivilege
> block in the init code in ZoneRulesProvider.

Ok, it is fine as is.  In retrospect, I would probably have tried to keep
the doPriveleged block as close to and as narrow as possible around
the privileged operations; in this case the property check and the file 
open.
>
>
>> It is not new but is that correct?
>>
>> Was there an opportunity to check the performance before and after both
>> in the local a remote cases?  tzdb.dat  frequently needs to be read and
>> contributes to startup latency.
>
> The tzdb.dat should only be read in once in normal use scenario. The 
> buffered
> stream has limited help in local case, I had measured it lots of time 
> during
> last round. It definitely should help the "high-latency" remove 
> scenario though.
> I can measure the local case again before push, if desirable.

While tracking down JDK-8023639 
<https://bugs.openjdk.java.net/browse/JDK-8023639>, it was noticed that 
some of the latency
was do to initializating both TimeZone.getDefault and 
ZoneRulesProvider.getRules.

No need for more work if the buffered version does not improve startup.

Thanks, Roger

>
> -Sherman
>
>>
>> (Not a Reviewer),
>>
>> Roger
>>
>>
>> On 10/15/2013 3:35 PM, Xueming Shen wrote:
>>> Hi,
>>>
>>> Please help codereview the changes for
>>>
>>> 8025971: Remove Time-Zone IDs HST/EST/MST
>>> 8026197: Slow reading tzdb.dat if the JRE is on a high-latency, 
>>> remote file system
>>>
>>> http://cr.openjdk.java.net/~sherman/8025971_8026197/webrev
>>>
>>> Note: for 8026197, the only real native resource here needed to be 
>>> taken care is
>>> the FIS. The only thing can go wrong during the creation chain 
>>> appears to be the
>>> use scenario that the jvm runs out of memory, which means we are in 
>>> bigger trouble
>>> (given this is being run at the beginning of vm start in most use 
>>> scenario) than the
>>> release of the native resource. And the FIS resource will actually 
>>> be released via
>>> finalizer, even it fails to get released proactively here. So I 
>>> still go with the "embedded"
>>> style here. I did not use the explicit "32000" buffer size as well. 
>>> Using the default 8k
>>> buffer size can save us a memory allocation at the FIS's native code 
>>> and remove the
>>> dependency on a specific size of the tzdb file (for this particular 
>>> release).
>>>
>>> Thanks,
>>> -Sherman
>>
>