Issue metadata
Sign in to add a comment
|
36 Kb regression in resource_sizes (MonochromePublic.apk) at 520046:520046) |
||||||||||||||||||
Issue descriptionCaused by "Revert "Revert "[wasm] JIT using WasmCodeManager""" Commit: a027c5408d5daf209dbe58986f68c271138b983b (v8 commit: b03b1bd9a87aa34380d62eb5bf42d52ba919f2f3) Link to size graph: https://chromeperf.appspot.com/report?sid=a097e74b1aa288511afb4cb616efe0f95ba4d347ad61d5e835072f23450938ba&num_points=10&rev=520046 Debugging size regressions is documented at: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/apk_size_regressions.md#Debugging-Apk-Size-Increase It's not clear to me whether or not this increase was expected. Please have a look and either: Close as “Won't Fix” with a short justification, or Land a revert / fix-up.
,
Nov 29 2017
See attached diff for more details.
,
Nov 29 2017
If I understand this correctly, this observes a 36KB growth in what probably is native libraries. This is expected with this change. It added, behind a flag, a secondary mechanism for allocating executable code for wasm. The growth is temporary. Once we gain confidence in the new feature, we will enable the flag by default, and then, once we believe we do not need a 'fast way to revert to the old mechanism', delete the old code.
,
Dec 8 2017
Makes sense! Should we keep this bug open to make sure the old code paths are removed?
,
Dec 8 2017
Yes, but we need to remove the target milestone and lower priority, because we will probably want to keep the old paths for a milestone (at most, I hope). Just in case we need a quick revert.
,
Dec 8 2017
,
Jan 10 2018
,
Feb 28 2018
The NextAction date has arrived: 2018-02-28
,
Feb 28 2018
|
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Nov 29 2017