| 60226561d5af59bc47ee70a4988633050e6fc62e |
|
17-Jul-2014 |
Neil Fuller <nfuller@google.com> |
Add a cache for ZoneInfo objects in Java
This mirrors the single-item cache in localtime.c.
This is in preparation for an upcoming change to migrate
android.format.text.Time over to Java. It will be making
use of the Java ZoneInfo instead of the native
equivalent.
The Java cache has a size of 1 like the bionic one,
though this can easily be increased.
Given the default TimeZone / ZoneInfo was always
pinned, in many cases the memory usage will not
go up noticeably. In scenarios where applications load
timezones besides the default a cache size of 1 potentially
increases pinned memory usage by one ZoneInfo plus
the overhead of the prototype object held by the cache
(which is never returned to callers).
An example ZoneInfo is "Europe/London", which has ~190
transitions (1 int + 1 byte) and ~6 types (1 int + 1 byte).
Overhead of other fields is ~ 13 bytes, plus the ID string.
190 * (4 + 1) + 6 * (4 + 1) + 13 = 993 bytes.
The prototypes held by the cache share the majority of their
memory with their clones returned from
ZoneInfo.makeTimeZone() and so the overhead of introducing
the cache itself should be in the order of a few tens of
bytes at most.
In future we may want to increase the cache size to 2 in
order to support apps that compare / switch timezones to
increase the odds of the default remaining in the cache.
Sizes above 2 look increasingly specialist.
LMP cherry-pick notes: This is a cherry-pick of the final
patch. In master, an original patch was reverted and then
the revert was reverted with an added fix. The comment
above is from the original commit. The fixed version
included:
Contains a fix for when the timezone ID is not found.
This includes a new test.
(cherry picked from d3d39ab8df5c4f6ae663613dc3617ba300282315)
Change-Id: I4c145942b6603e0e62badfd052b5716fd68769d2
|
| d3d39ab8df5c4f6ae663613dc3617ba300282315 |
|
17-Jul-2014 |
Neil Fuller <nfuller@google.com> |
Revert "Revert "Add a cache for ZoneInfo objects in Java""
This reverts commit 01b6a878d10ee68db87c3d85d137e81a5257a78a.
Contains a fix for when the timezone ID is not found.
This includes a new test.
Change-Id: I2e5e669782ea6caf4e97153ed6b63ca6ee4ef50d
|
| 01b6a878d10ee68db87c3d85d137e81a5257a78a |
|
17-Jul-2014 |
Neil Fuller <nfuller@google.com> |
Revert "Add a cache for ZoneInfo objects in Java"
This reverts commit a6e8689807f5a8bb9470ce7c26a47455d2d0608d.
Change-Id: I17a0262d169db3418f2f8888195381f778975dc4
|
| a6e8689807f5a8bb9470ce7c26a47455d2d0608d |
|
16-Jul-2014 |
Neil Fuller <nfuller@google.com> |
Add a cache for ZoneInfo objects in Java
This mirrors the single-item cache in localtime.c.
This is in preparation for an upcoming change to migrate
android.format.text.Time over to Java. It will be making
use of the Java ZoneInfo instead of the native
equivalent.
The Java cache has a size of 1 like the bionic one,
though this can easily be increased.
Given the default TimeZone / ZoneInfo was always
pinned, in many cases the memory usage will not
go up noticeably. In scenarios where applications load
timezones besides the default a cache size of 1 potentially
increases pinned memory usage by one ZoneInfo plus
the overhead of the prototype object held by the cache
(which is never returned to callers).
An example ZoneInfo is "Europe/London", which has ~190
transitions (1 int + 1 byte) and ~6 types (1 int + 1 byte).
Overhead of other fields is ~ 13 bytes, plus the ID string.
190 * (4 + 1) + 6 * (4 + 1) + 13 = 993 bytes.
The prototypes held by the cache share the majority of their
memory with their clones returned from
ZoneInfo.makeTimeZone() and so the overhead of introducing
the cache itself should be in the order of a few tens of
bytes at most.
In future we may want to increase the cache size to 2 in
order to support apps that compare / switch timezones to
increase the odds of the default remaining in the cache.
Sizes above 2 look increasingly specialist.
Change-Id: I0b7daa8ad5d334c8d421dfaa6e0421d3c181a915
|
| c84389115f1f115cb17036905650c63526315245 |
|
02-Jun-2014 |
Neil Fuller <nfuller@google.com> |
Fix ZoneInfoDBTest.testGoodOverride
When executed under the CTS environment some of the tests in
ZoneInfoDBTest assumed:
1) The device was booted with all tzinfo files present and that
they don't change (i.e. so the runtime's static TimeZone
singleton reflects the contents of the file system at the
time the test is executed).
2) The number of timezone IDs in /data/misc/zoneinfo/tzdata,
/system/usr/share/zoneinfo/tzdata are the same (if
assumption 1 holds).
This change modifies the tests to only use the (unchanging)
/system/usr/share/zoneinfo/tzdata file and avoid use of the
TimeZone class.
Bug: 15382201
Change-Id: I8d3b1ea52a2147e7afaa302803c834539bd01db9
|
| 74bdf4bf4e35958cb36c73bd9f9a3098e7255412 |
|
07-Nov-2013 |
Elliott Hughes <enh@google.com> |
The file in /data overrides the file in /system, not the other way round.
Bug: 11513357
(cherry picked from commit 19263f5b82e89ac1a9cf11a8bdb50076f72ff781)
Change-Id: I84dd9f7407300d0012c6af7d323a2a56030453fb
|
| 19263f5b82e89ac1a9cf11a8bdb50076f72ff781 |
|
07-Nov-2013 |
Elliott Hughes <enh@google.com> |
The file in /data overrides the file in /system, not the other way round.
Bug: 11513357
Change-Id: Ib8a6c2574eb2aef85c4224f0c640ab9b883713c5
|
| 080690965038c72ff38bcde4ce247ced533b4d89 |
|
04-Nov-2013 |
Elliott Hughes <enh@google.com> |
Fix ZoneInfoDBTest on devices that have taken a gservices tzdata update.
The tests were assuming that the zygote was always using the
/system/usr/share/zoneinfo copy, but devices that have taken a gservices tzdata
update will be using the /data/misc/zoneinfo/tzdata copy instead.
Bug: 11513357
(cherry picked from commit e086850abf2726d5b5af1d9286fdb32f7146fad3)
Change-Id: If9047a0678efb7bcfe0838cbe602a9c906e1f907
|
| e086850abf2726d5b5af1d9286fdb32f7146fad3 |
|
04-Nov-2013 |
Elliott Hughes <enh@google.com> |
Fix ZoneInfoDBTest on devices that have taken a gservices tzdata update.
The tests were assuming that the zygote was always using the
/system/usr/share/zoneinfo copy, but devices that have taken a gservices tzdata
update will be using the /data/misc/zoneinfo/tzdata copy instead.
Bug: 11513357
Change-Id: Ieb5c28f91445630f6b00e18aefff0c234c223d97
|
| a4f83b14ca640c0ed527c12c54c77462c071b5c8 |
|
27-Apr-2013 |
Elliott Hughes <enh@google.com> |
Fix ZoneInfoDBTest.
I'm so stupid. frameworks/base wasn't the only caller.
Change-Id: Ia0c3ce79e2f899e77a9cd1e62fca7d3b22130cf2
|
| 995caee51334a4f1a1429e29680ea079c900c37a |
|
25-Apr-2013 |
Elliott Hughes <enh@google.com> |
Cope with a corrupt tzdata update.
We need to fall back to the next choice on error. Rewrite the code
to be testable and add some tests. Add an internal GMT-only
fallback in case all our sources of tzdata are bad. Also make
time zone detection on the host more useful.
Bug: 8373554
Change-Id: I9f91b844a61f07f34b268535e6d24aa0c301bf8d
|