On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote:
> There's also a pre-processor constant that we define in Valgrind/ASAN/etc. > builds that you can check in order to free more stuff than you otherwise > would. But I can't for the life of me remember what it's called :( > NS_FREE_PERMANENT_DATA. Please don't just cobble together your own, as this will work in all of the various configurations we care about for leak checking, present and future, without any further work. Nick > > On Sat, May 20, 2017 at 5:09 AM, Jeff Muizelaar <jmuizel...@mozilla.com> > wrote: > > > We use functions like cairo_debug_reset_static_data() on shutdown to > > handle cases like this. > > > > -Jeff > > > > On Fri, May 19, 2017 at 1:44 AM, Henri Sivonen <hsivo...@hsivonen.fi> > > wrote: > > > On Tue, May 16, 2017 at 7:03 AM, Tim Guan-tin Chien > > > <timdr...@mozilla.com> wrote: > > >> According to Alexa top 100 Taiwan sites and quick spot checks, I can > > only > > >> see the following two sites encoded in Big5: > > >> > > >> http://www.ruten.com.tw/ > > >> https://www.momoshop.com.tw/ > > >> > > >> Both are shopping sites (eBay-like and Amazon-like) so you get the > idea > > how > > >> forms are used there. > > > > > > Thank you. It seems to me that encoder performance doesn't really > > > matter for sites like these, since the number of characters one would > > > enter in the search field at a time is very small. > > > > > >> Mike reminded me to check the Tax filing website: > > http://www.tax.nat.gov.tw/ > > >> .Yes, it's unfortunately also in Big5. > > > > > > I guess I'm not going to try filing taxes there for testing. :-) > > > > > > - - > > > > > > One option I've been thinking about is computing an encode > > > acceleration table for JIS X 0208 on the first attempt to encode a CJK > > > Unified Ideograph in any of Shift_JIS, EUC-JP or ISO-2022-JP, for GBK > > > on the first attempt to encode a CJK Unified Ideograph in either GBK > > > or gb18030, and for Big5 on the first attempt to encode a CJK Unified > > > Ideograph in Big5. > > > > > > Each of the three tables would then remain allocated through to the > > > termination of the process. > > > > > > This would have the advantage of not bloating our binary footprint > > > with data that can be computed from other data in the binary while > > > still making legacy Chinese and Japanese encode fast without a setup > > > cost for each encoder instance. > > > > > > The downsides would be that the memory for the tables wouldn't be > > > reclaimed if the tables aren't needed anymore (the browser can't > > > predict the future) and executions where any of the tables has been > > > created wouldn't be valgrind-clean. Also, in the multi-process world, > > > the tables would be recomputed per-process. OTOH, if we shut down > > > rendered processes from time to time, it would work as a coarse > > > mechanism to reclaim the memory is case Japanese or Chinese legacy > > > encode is a relatively isolated event in the user's browsing pattern. > > > > > > Creating a mechanism for the encoding library to become aware of > > > application shutdown just in order to be valgrind-clean would be > > > messy, though. (Currently, we have shutdown bugs where uconv gets used > > > after we've told it can shut down. I'd really want to avoid > > > re-introducing that class of bugs with encoding_rs.) > > > > > > Is it OK to create allocations that are intentionally never freed > > > (i.e. process termination is what "frees" them)? Is valgrind's message > > > suppression mechanism granular enough to suppress three allocations > > > from a particular Rust crate statically linked into libxul? > > > > > > -- > > > 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 > > > _______________________________________________ > 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
