Issue metadata
Sign in to add a comment
|
Experiment with zipping packed relocations (100kb savings) |
||||||||||||||||||||||
Issue descriptionlibchrome.so on Android usee packed relocations to shrink the size of .rel.dyn from (as of now): 2,709,016 bytes down to 341,528 However, gzipping the packed relocation further shrinks them to just 22,936 (320kb savings) One of the design goals of packed relocations is that unpacking is done in a streaming way. Gzip is compatible with this. The biggest unknown to me is whether WebView / Monochrome will be able to take advantage of zipping these, as it would re-introduce dependence on our custom linker. One alternative to a custom linker is adding an entry to .init_array that performs the relocations (bundle the relocation code), but this is much more complex and might be incompatible with relocation sharing. Packed relocations references: https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/ https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/src/delta_encoder.h Support for packed relocations was added directly to Android's linker in M: https://android-review.googlesource.com/#/c/135550/ How I calculated savings: Show size of .rel.dyn before packing: readelf -S out/Release/libchrome.so Show size of .rel.dyn after packing: unzip out/Release/apks/Chrome.apk lib/armeabi-v7a/libchrome.so readelf -S lib/armeabi-v7a/libchrome.so Show size of it gzipped: objdump -h lib/armeabi-v7a/libchrome.so | grep .rel.dyn | awk '{print "dd if='lib/armeabi-v7a/libchrome.so' of='dyn.rel' bs=1 count=$[0x" $3 "] skip=$[0x" $6 "]"}' | bash ls -l dyn.rel Assigning to torne@ to comment on whether this is an issue for webview.
,
Jan 18 2017
Okay, that's what I was afraid of :/ So we could apply this for pre-monochrome via custom linker, but not for webview nor monochrome unless we add it to android's linker.
,
Feb 3 2017
digit - noticed your name in the crazy linker code... Any desire to work on this?
,
Feb 13 2017
,
Feb 13 2017
,
May 9 2017
,
Jul 22 2017
Updated number now that we've switched to clang. For libmonochrome.so, dyn.rel: 353496 dyn.rel.gz: 20412 (94% compression)
,
Sep 14 2017
And for interest's sake, using zopfli gives: dyn.rel.zopfli: 18179 (95% compression)
,
Sep 18 2017
Another data point using lz4 compression: $ ./lz4 -12 -B4 -BD dyn.rel dyn.rel.lz4 using blocks of size 64 KB Compressed 373136 bytes into 28569 bytes ==> 7.66% This is probably a better format to use since it decompresses ~10x faster.
,
Sep 18 2017
True, but this adds an lz4 decompressor to the linker. I hope this is less than 300 KiB, otherwise we have a problem. There is no such issue when using zlib which is part of the platform :)
,
Sep 18 2017
Actually, it looks like an lz4 decompressor can be very small, see the "LZ4 decompressor" section at: http://create.stephan-brumme.com/smallz4/#numbers
,
Sep 20 2017
Using non-streaming lz4hc (lower decode ram requirement): libchrome.so = 28764 (92% compression) (64k chunks) libchrome.so = 29874 (92% compression) (32k chunks) libchrome.so = 31065 (91.5% compression) (16k chunks) Using lz4hc without Sleb128 encoding: libchrome.so = 38122 (89.5% compression) (64k chunks) My guess is that the vast majority of ints fit into a single byte, which is why sleb128 is still beneficial even with compression.
,
Feb 7 2018
The proposal for RELR relocations is here: https://groups.google.com/d/msg/generic-abi/bX460iggiKg/Pi9aSwwABgAJ For Chrome, this would shrink our .rel.dyn 181025 -> ~80kb, and improve start-up time (55ms to apply relocations vs 15ms on my Moto G first gen). This shrinks the size of arm64 drastically more (by MBs), but not super relevant because... We would not be able to use this for Monochrome. Webview is always loaded using the system linker.
,
Feb 7 2018
Note: Biggest blocker here is getting it implemented in lld.
,
Aug 1
,
Oct 15
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by torne@chromium.org
, Jan 18 2017