Re: Dropping support for MSVC2012
On 04/01/15 19:28, Philip Chee wrote: > To me, the default answer to whether we should keep supporting MinGW > is "no", merely because it will require time and effort that will not > directly benefit our users as we do not use that compiler to release > Firefox. That is, without someone coming up with a good reason > otherwise, we should drop it. And not having it locally installed is > not a good reason. :-) I believe the Tor project uses it for reproducible builds on Windows: https://air.mozilla.org/why-and-how-of-reproducible-builds-distrusting-our-own-infrastructure-for-safer-software-releases/ Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 03/01/2015 04:22, Ehsan Akhgari wrote: > To me, the default answer to whether we should keep supporting MSVC2012 > is "no", merely because it will require time and effort that will not > directly benefit our users as we do not use that compiler to release > Firefox. That is, without someone coming up with a good reason > otherwise, we should drop it. And not having it locally installed is > not a good reason. :-) To me, the default answer to whether we should keep supporting MinGW is "no", merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) Phil -- Philip Chee , http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What does the sameZoneAs option on the Cu.Sandbox do?
I forgot to mention that this also impacts regular garbage collection. In some cases, the GC will try to clean up just one zone (this is useful when you have one tab that generated lots of garbage while the rest of your tabs just sat there). When this happens, the GC has to assume that anything pointed to from outside the zone is definitely alive (even though the stuff pointing to it might, in fact, be dead). So it's advantageous to group globals that hold lots of references to each other in the same zone, since it increases the amount of memory that the GC can clean up during a single-zone GC. On Sat, Jan 3, 2015 at 7:05 AM, Naja Melan wrote: > Naja Melan: > > ok, > > > > thanks, now it all makes sense ;) > > > Except for one thing. Sorry to be nitpicking, but the MDN page now says: > > sameZoneAs: A JavaScript object in whose garbage collection region the > sandbox should be created in. This helps to improve memory usage by > allowing sandboxes to be discarded when that zone goes away. Content > scripts pass the window they're running in as this parameter, in order to > ensure that the script is cleaned up at the same time as the content itself. > > This seems to claim that by setting this option will discard your sandbox > automatically and that it ensures scripts will be cleaned up when the > window is cleaned up. That seems in contradiction with what Bobby Holley > explains. > > I would suggest a wording like: > > A JavaScript object in whose garbage collection region the sandbox should > be created in. Objects created in the same garbage collection region will > be allocated in the same block of heap memory, so if they are all freed at > the same time the garbage collector can liberate bigger blocks of memory at > once which reduces memory consumption [[or is it just a question of > performance]]. For content scripts you should pass the window your script > runs in as this option. You still have to use Components.utils.nukeSandbox > or stop holding references to your sandbox when the user closes the browser > tab for this to have effect. > > Naja Melan > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What does the sameZoneAs option on the Cu.Sandbox do?
Naja Melan: > ok, > > thanks, now it all makes sense ;) > Except for one thing. Sorry to be nitpicking, but the MDN page now says: sameZoneAs: A JavaScript object in whose garbage collection region the sandbox should be created in. This helps to improve memory usage by allowing sandboxes to be discarded when that zone goes away. Content scripts pass the window they're running in as this parameter, in order to ensure that the script is cleaned up at the same time as the content itself. This seems to claim that by setting this option will discard your sandbox automatically and that it ensures scripts will be cleaned up when the window is cleaned up. That seems in contradiction with what Bobby Holley explains. I would suggest a wording like: A JavaScript object in whose garbage collection region the sandbox should be created in. Objects created in the same garbage collection region will be allocated in the same block of heap memory, so if they are all freed at the same time the garbage collector can liberate bigger blocks of memory at once which reduces memory consumption [[or is it just a question of performance]]. For content scripts you should pass the window your script runs in as this option. You still have to use Components.utils.nukeSandbox or stop holding references to your sandbox when the user closes the browser tab for this to have effect. Naja Melan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
