diff options
| author | Tobias Thierer <tobiast@google.com> | 2019-10-04 00:47:53 +0100 |
|---|---|---|
| committer | Tobias Thierer <tobiast@google.com> | 2019-10-04 13:03:06 +0100 |
| commit | 364631f684698cd2bb5be93ce82ca115390d3b29 (patch) | |
| tree | 2479e6c947ed9a3119c930ebc38036b1e94d2203 /annotations/generate_annotated_java_files.py | |
| parent | c83d0458abd1b897b50e6361084b35c46c44d97c (diff) | |
Construct default MimeMap lazily rather than eagerly.
A side effect of CL topic r.android.com/q/topic:bug136256059_attempt2
was that the default MimeMap instance is now loaded eagerly (pre-fork)
regardless of whether any app process ends up using it, whereas
previously it was loaded lazily (post-fork) the first time an app
process used it.
This traded off CPU and memory use post-fork vs. pre-fork. Because it
isn't known / hasn't been proven whether and how many app processes
use that instance, the net CPU and memory impact is not known: if at
least one process makes use of a relevant API, the net impact will be
neutral or positive, or else negative.
Until this can be investigated and undergo system health review, this
CL topic changes the behavior back to post-fork lazy loading of the
default MimeMap instance.
Bug: 142019040
Test: atest CtsLibcoreTestCases:libcore.libcore.content.type.MimeMapTest
Test: atest CtsMimeMapTestCases
Change-Id: I85897293afc83044c07e1f03b0d57b10f5798ecd
Diffstat (limited to 'annotations/generate_annotated_java_files.py')
0 files changed, 0 insertions, 0 deletions