I second Kris' concern re: memory, particularly given this is in multiple processes. I'd suggest something more along the lines of a timeout; AFAICT 'memory-pressure' isn't actually fired in low-memory situations (it's still useful, and registering for it and handling it would make sense for anything that's caching large amounts of data). I'd certainly want to see measurements on what the actual overhead is.
In general I'm not super concerned about leaking at shutdown, but of course as you noted V, lsan, etc are and it makes life harder for our leak checking frameworks. Kris and Jeff's suggestions seem reasonable. I'd be less concerned about overhead if we had a good way of sharing these static tables across processes (ICU seems like a good candidate as well). -e On Fri, May 19, 2017 at 11:58 AM, Kris Maglione <kmagli...@mozilla.com> wrote: > On Fri, May 19, 2017 at 08:44:58AM +0300, Henri Sivonen wrote: > >> 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. >> > > If we do this, it would be nice to flush the tables when we get a > memory-pressure event, which should at least mitigate some of the effects > for users on memory-constrained systems. > > And is there a reason ClearOnShutdown couldn't be used to deal with > valgrind issues? > > That said, can we try to get some telemetry on how often we'd need to > build these tables, and how likely they are to be needed again in the same > process, before we make a decision? > > _______________________________________________ > 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
