2011/11/12 Jesse Ruderman <
jrud...@gmail.com>:
>> To make any kind of estimates about stability improvements that could come from a 64-bit Firefox, we need to understand more about the RAM available on our 64-bit Windows users' systems and how much of Firefox's usage is backed by memory and how much is mmaped files.
>
> I'm curious why this is relevant. I assumed both contributed equally
> to VM size, which is what is relevant for out-of-VM-space crashes.
>
>> 64-bit could offer gains for software rendering of features like WebGL. This is because SSE2 is always available in 64-bit. (We currently only support WebGL for ~40% of our users because it's dependent on hardware rendering.) But SSE2 isn't enough, alone, to get the big gains we'd want here. Those would require code changes which we have yet to do like SIMD work.
>
> Are you implying that with SSE2 available and some SIMD coding, we'd
> be able to turn on WebGL for users without supported graphics cards?
> That would be pretty cool, actually.
There is that idea on the horizon, to use a software OpenGL renderer
to enable WebGL where we don't have GPU-hardware-accelerated OpenGL.
The main problem is of course that software OpenGL rendering is slow;
but this is exactly the kind of big number crunching task where 64bit
and SSE2 would help.
If one wants to get concrete measurement, build a given fast software
OpenGL renderer in 32bit and in 64bit and compare the speed the two
versions give on some WebGL demo. A good example of a fast software
OpenGL renderer is Mesa3D's llvmpipe.
http://www.phoronix.com/scan.php?page=article&item=llvmpipe_summer_2011&num=1
Benoit
>
> There may be other ways to get these SSE2 benefits (e.g. a stub
> installer picking a 32-bit version with or without SSE2, or runtime
> checks around the software rendering code).
>
>> We can make the 64-bit jitcode equal to or better than the 32-bit jitcode on Windows 7, if we are willing to limit JS to using < 2GB of memory for objects, strings, and functions. If we are unwilling to accept that limitation, it's less clear if there's a win there.
>
> I guess we should look at our telemetry data to see how much memory JS
> is using, when Firefox is "using lots of memory". If the answer is
> "when Firefox is using lots of memory, most of it tends to be JS" then
> this would be dropping the stability win of 64-bit :/
>
> Could Firefox start in "fast, small" mode but discard/recompile all
> the JIT code if it needs to move into "slower, bigger" mode?
>
>> 64-bit Firefox will, in most cases, use more more memory than 32-bit Firefox. For systems that have limited RAM, this could lead to more OOMs, not less.
>
> You mean 64-bit systems with less than 4GB total of RAM and swap? That
> sounds unlikely.
>
>> Applications which work by hooking DLLs into Firefox's address space will no longer work with 64-bit versions. The most important example of this type of application are accessibility clients.
>
> Maybe we can work with NVDA (open source screen reader) to ensure it's possible?
>
>> Flash, Java, and Silverlight all have 64-bit Windows NPAPI plug-ins, though at differing levels of completeness.
>
> I guess it would be nice to have plugin discovery ironed out before
> releasing a Firefox that's not compatible with already-installed
> Flash.
>
>> We don't have comparative stability and performance data between 32-bit and 64-bit Firefoxen on 64-bit and 32-bit Windows
>
> Is Mac or Linux data useful at all here? (Or for estimating the memory
> use difference, for that matter.)
> _______________________________________________
> dev-planning mailing list
>
dev-pl...@lists.mozilla.org
>
https://lists.mozilla.org/listinfo/dev-planning
>