https://github.com/libav/libav/blob/master/doc/tablegen.txt See also bug 1254777 comment 4.

Are these tables always generated at runtime, or only on demand? If it's the latter, and the demand is infrequent, it might be worth keeping the runtime generation because they are in the .bss segment and so use only address space prior to generation.

Here are the sizes of all the tables, which in combination are 655,280 bytes(!) > 0x20000 ff_cos_65536 > 0x20000 ff_sin_65536 > 0x10000 ff_cos_32768 > 0x10000 ff_cos_65536_fixed > 0x10000 ff_sin_32768 > 0x8000 ff_cos_16384 > 0x8000 ff_cos_32768_fixed > 0x8000 ff_sin_16384 > 0x4000 ff_cos_16384_fixed > 0x4000 ff_cos_8192 > 0x4000 ff_sin_8192 > 0x2000 ff_cos_4096 > 0x2000 ff_cos_8192_fixed > 0x2000 ff_sin_4096 > 0x1000 ff_cos_2048 > 0x1000 ff_cos_4096_fixed > 0x1000 ff_sin_2048 > 0x800 ff_cos_1024 > 0x800 ff_cos_2048_fixed > 0x800 ff_sin_1024 > 0x400 ff_cos_1024_fixed > 0x400 ff_cos_512 > 0x400 ff_sin_512 > 0x200 ff_cos_256 > 0x200 ff_cos_512_fixed > 0x200 ff_sin_256 > 0x100 ff_cos_128 > 0x100 ff_cos_256_fixed > 0x100 ff_sin_128 > 0x80 ff_cos_128_fixed > 0x80 ff_cos_64 > 0x80 ff_sin_64 > 0x40 ff_cos_32 > 0x40 ff_cos_64_fixed > 0x40 ff_sin_32 > 0x20 ff_cos_16 > 0x20 ff_cos_32_fixed > 0x20 ff_sin_16 > 0x10 ff_cos_16_fixed The cos tables are initialized in ff_init_ff_cos_tabs(), and AFAICT that is not called automatically at start-up. Presumably it's only called on demand. So leaving them in .bss might be best. I can't work out where the sin tables are initialized.

(In reply to Nicholas Nethercote [:njn] from comment #2) > The cos tables are initialized in ff_init_ff_cos_tabs(), and AFAICT that is > not called automatically at start-up. Presumably it's only called on demand. > So leaving them in .bss might be best. Aren't they initialized here [1] and the sin ones here [2]? 'ff_init_ff_cos_tabs' initializes 'ff_cos_tabs', no? Looks like 'ff_sin_tabs' is initialized here [3]. [1]: http://hg.mozilla.org/mozilla-central/file/a235bfcc8c41/media/libav/libavcodec/fft_template.c#l35 [2]: http://hg.mozilla.org/mozilla-central/file/a235bfcc8c41/media/libav/libavcodec/rdft.c#l31 [3]: http://hg.mozilla.org/mozilla-central/file/a235bfcc8c41/media/libav/libavcodec/rdft.c#l117

I don't see ff_cos_32768 and the like in the output of njn's script from bug 1254777 any more. I'm not sure if that's an issue with the script or what. We still build that code, so I have no idea why it is not showing up.

Oh, right, it isn't in libxul. I found it in another one of the .so files.

The all.syms file produced by the script is the combination of all the individual .syms files, so look at that file for the complete picture.

I looked at this a little bit, but I think I have ideas related to reducing content process memory usage that are more important than this, so I'm not going to look at it any more. These tables look like they are only initialized for some Web Audio stuff.

The best solution here is probably to move libav into a single GMP sandbox process.

I don't think this is really 655kb of memory. Per comment 1, these only use address space until the tables are generated, and presumably most processes aren't playing whatever media format this is. (Address space is not going to be at a premium in the Fission world.)

libav is being removed in bug 1476231, so I guess we can dupe this to that?

These are used for certain Web Audio node types. The tables are generated on-demand and only when required for those types. Bug 1476231 doesn't really completely fix this bug because it replaces the Libav code with similar FFmpeg code. However, the FFmpeg code is sensible enough to generate only cos tables, because sin tables contain the same data in different places, and so the used overhead is reduced considerably. The changes in Bug 1476231 also do not include the unused _fixed tables. I would guess that the proportion of processes using Web Audio is small enough that the extra memory used by these processes is worth the saving in binary size. Also note that Web Audio only uses FFTs of size up to 32768. FFmpeg has tables for 65536 and 131072. Even if Gecko ended up generating all tables that it might ever use, it would use about 128kB. If generating at build time, then 512kB would be generated, and a maximum of one quarter used, unless the code were patched.