2014-04-25 3:31 GMT-04:00 Henri Sivonen <hsivo...@hsivonen.fi>: > On Thu, Apr 24, 2014 at 4:20 PM, Benoit Jacob <jacob.benoi...@gmail.com> > wrote: > > 2014-04-24 8:31 GMT-04:00 Henri Sivonen <hsivo...@hsivonen.fi>: > > > >> I have prepared a queue of patches that removes Netscape-era (circa > >> 1999) internationalization code that efforts to implement the Encoding > >> Standard have shown unnecessary to have in Firefox. This makes libxul > >> on ARMv7 smaller by 181 KB, so that's a win. > > > > Have we measured the impact of this change on actual memory usage (as > > opposed to virtual address space size) ? > > No, we haven't. I don't have a B2G phone, but I could give my whole > patch queue in one diff to someone who wants to try. > > > Have we explored how much this problem could be automatically helped by > the > > linker being smart about locality? > > Not to my knowledge, but I'm very skeptical about getting these > benefits by having the linker be smart so that the dead code ends up > on memory pages that aren't actually mapped to real RAM. > > The code that is no longer in use is sufficiently intermingled with > code that's still is in use. Useful and useless plain old C data is > included side-by-side. Useful and useless classes are included next to > each other in unified compilation units. Since the classes are > instantiated via XPCOM, a linker that's unaware of XPCOM couldn't tell > that some classes are in use and some aren't via static analysis. All > of them would look equally dead or alive depending on what we do you > take on the root of the caller chain being function pointers in a > contract ID table. > > Using PGO to determine what's dead code and what's not wouldn't work, > either, if the profiling run was "load mozilla.org", because the run > would exercise too little code, or if the profiling run was "all the > unit tests", because the profiling run would exercise too much code. >
Thanks for this answer, it does totally make sense (and shed light on the specifics here that make this hard to solve automatically). Benoit > > On Fri, Apr 25, 2014 at 2:03 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > >> * Are we building and shipping dead code in ICU on B2G? > > > > No. That is at least partly covered by bug 864843. > > Using system ICU seems wrong in terms of correctness. That's the > reason why we don't use system ICU on Mac and desktop Linux, right? > > For a given phone, the Android base system practically never updates, > so for a given Firefox version, the Web-exposed APIs would have as > many behaviors as there are differing ICU snapshots on different > Android versions out there. > > As for B2G, considering that Gonk is supposed to update less often > than Gecko, it seems like a bad idea to have ICU be part of Gonk > rather than part of Gecko on B2G. > > > In my experience, ICU is unfortunately a hot potato. :( The real blocker > > there is finding someone who can tell us what bits of ICU _are_ used in > the > > JS engine. > > Apart from ICU initialization/shutdown, the callers seem to be > http://mxr.mozilla.org/mozilla-central/source/js/src/builtin/Intl.cpp > and http://mxr.mozilla.org/mozilla-central/source/js/src/jsstr.cpp#852 > . > > So the JS engine uses: > * Collation > * Number formatting > * Date and time formatting > * Normalization > > It looks like the JS engine has its own copy of the Unicode database > for other purposes. It seems like that should be unified with ICU so > that there'd be only one copy of the Unicode database. > > Additionally, we should probably rewrite nsCollation users to use ICU > collation and delete nsCollation. > > Therefore, it looks like we should turn off (if we haven't already): > * The ICU LayoutEngine. > * Ustdio > * ICU encoding converters and their mapping tables. > * ICU break iterators and their data. > * ICU transliterators and their data. > > http://apps.icu-project.org/datacustom/ gives a good idea of what > there is to turn off. > > > The parts used in Gecko for <input type=number> are pretty > > small. And of course someone needs to figure out the black magic of > > conveying the information to the ICU build system. > > So it looks like we already build with UCONFIG_NO_LEGACY_CONVERSION: > > http://mxr.mozilla.org/mozilla-central/source/intl/icu/source/common/unicode/uconfig.h#264 > > However, that flag is misdesigned in the sense that it considers > US-ASCII, ISO-8859-1, UTF-7, UTF-32, CESU-8, SCSU and BOCU-1 as > non-legacy, even though, frankly, those are legacy, too. (UTF-16 is > legacy also, but it's legacy we need, since both ICU and Gecko are > UTF-16 legacy code bases!) > > http://mxr.mozilla.org/mozilla-central/source/intl/icu/source/common/unicode/uconfig.h#267 > > So I guess the situation isn't quite as bad as I thought. > > We should probably set UCONFIG_NO_CONVERSION to 1 and > U_CHARSET_IS_UTF8 to 1 per: > > http://mxr.mozilla.org/mozilla-central/source/intl/icu/source/common/unicode/uconfig.h#248 > After all, we should easily be able to make sure that we don't use > non-UTF-8 encodings when passing char* to ICU. > > Also, If the ICU build system is an configurable enough, I think we > should consider identifying what parts of ICU we can delete even > though the build system doesn't let us to and then automate the > deletion as a script so that it can be repeated with future imports of > ICU. > > >> * Do we have any mechanisms in place for preventing stuff like the > >> ICU encoding converters becoming part of the building the future? > > > > No, that is not possible to automate. > > I was thinking of policy / review solutions. > > >> * How should we identify code that we build but that isn't used > >> anywhere? > > > > I'm afraid we need humans for that. > > Yeah, but how do we get humans to do that? > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
