| ea13f8291a92b6f47f50011da1d5e8c107984bc3 |
|
30-Nov-2015 |
Paul Duffin <paulduffin@google.com> |
Switch to latest version of Caliper
Convert the benchmarks to the latest version of Caliper.
Bug: 24848946
Change-Id: Iac04b30dac61ccb397a6685890da64bae4d3b318
|
| 2ce899fcb81707dd5447a15c29c2c137697f2f5e |
|
04-Jun-2015 |
Neil Fuller <nfuller@google.com> |
Revert "Revert "Modification to the way boot classpath resources are loaded""
This reverts commit 0c2e3c7fcb6754a2116c6226fe6480b3f6fa691f.
Change-Id: I37abbb83f6091f252c90645b8a088cf361fa6a7a
|
| 0c2e3c7fcb6754a2116c6226fe6480b3f6fa691f |
|
03-Jun-2015 |
Neil Fuller <nfuller@google.com> |
Revert "Modification to the way boot classpath resources are loaded"
This reverts commit 05a5c2f89e12e27db69f24165a05bdfd0476c73a.
Change-Id: I07cc3841df40d20e2c09b0bf282bf213f422effe
|
| 05a5c2f89e12e27db69f24165a05bdfd0476c73a |
|
19-May-2015 |
Neil Fuller <nfuller@google.com> |
Modification to the way boot classpath resources are loaded
VMClassLoader.getResource(), used by the Android boot classloader
was more expensive than it needed to be.
Context:
Checking each classpath entry for a resource involved opening a
zip file, checking for the resource and closing it again.
Because classloaders are arranged in a hierarchy, and parent
classloaders are checked first, this change should have a positive
performance impact for every call to ClassLoader.getResource(),
getResources() and getResourceAsStream(), regardless of the
classloader being used.
Details of change:
This change builds on an earlier commit for BaseDexClassLoader.
See commit 1a796cbc5dfb263511f2f4e5213adbc1d396a813 for the
earlier change. Unlike the BaseDexClassLoader change, we did
not have the zip file already open so this does impact the amount
of reported heap memory being used at rest in the zygote. It may
increase the amount of heap memory in use generally for jars
that have no resources because all jar files are opened, not
just the ones found to have requested resources. The heap memory
should consist of the entry metadata. The zip file itself is
mapped into non-heap/native memory.
Any resources loaded from the boot classloader previously
would have caused the JarURLConnection cache to hold the
associated zip file open anyway. See
https://code.google.com/p/android/issues/detail?id=60071 for
context. This change avoids the use of that cache for bootclass
path resources. Most other usages of jar: urls should now be
within the control of apps, and their can call setUseCache() to
prevent caching.
Performance:
Measured on a Nexus 5. All values in microseconds.
Benchmark (not real app):
GetBootResource_hit - looks for a resource known to be in the
boot classpath in core-libart: java/util/logging/logging.properties
GetBootResource_miss - looks for a resource known to be missing.
Before:
GetBootResource_hit 237
GetBootResource_miss 3034
After:
GetBootResource_hit 23.8
GetBootResource_miss 22.5
App (using vogar --mode activity):
Before:
Hit: 236-446
Miss: 3042-3555
After:
Hit: 65-180
Miss: 88-120
Memory usage:
The use of StrictJarFile keeps the memory usage down to low levels
levels: An initial implementation of this change that used JarFile
was showing up as expensive because the heap memory usage is
dependent on the number of entries in the jar. ext.jar was taking
up 275k due to a large number of resources associated with
libphonenumber. By using StrictJarFile, Java heap usage is now < 2k
per jar. The JarFile cost would previous have been paid anyway
if an app read a resource out of ext.jar (because of the
JarURLConnectionImpl cache) so this change should also produce savings
there. It does mean that we map all the class path jars into memory
natively, but the kernel should be managing that for us and sharing
the expense across all apps.
Given the runtime may be mapping the files for its own purposes
elsewhere the additional cost may even be nil.
Bug: https://code.google.com/p/android/issues/detail?id=60071
Bug: 20685844
Change-Id: Ic3dc4a655c46cc67bfe9b9e254036c6651869c92
|