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
