[threeten-dev] TzdbZonRulesProvider and providerBind

Xueming Shen xueming.shen at oracle.com
Mon Jan 28 14:05:09 PST 2013


Stephen,

While working on the "j.u.TimeZone uses tzdb.jar" code [1], I just
realized the "supposedly to be the optimization helper" BoundProvider
actually stands in the way of performance. It forces the rules to be
loaded eagerly, with hundreds of BoundProvider objects flying in
the startup stage. It basically disables any lazy-loading design/impl
and possible provider hashing mechanism by eagerly loading the
rules into ZoneRulesProvider level. Interestingly, the spec suggests
that "this is suitable for providers that cann't change their contents
during the lifetime of the JVM", exactly what the TzdbZoneRuleProvider
is supposed to be, but "can't not change their contents during lifetime"
does not necessarily mean "have to eagerly loading everything at
start", given in most use scenario, only limited zones are used, it's
really not a good strategy.

Given its only benefit appears to replace two hash mapping lookups
by one (also, I don't think it's a good idea for the spi abstract class
to get into the business of how the individual provider takes care of
their zoneid->rules implementation). I would suggest we just remove
the mechanism.

Here is webrev that
(1) disabled the mechanism (I hope you agree to simply remove it)
(2) replaced the id->index->byte[]/rules lookup to id -> byte[]/rules
      (least, we don't have to do binary search )

http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzdbProvider/

-Sherman

[1] http://cr.openjdk.java.net/~sherman/jdk8_threeten/tz_share/


More information about the threeten-dev mailing list