Re: Virtual Memory fragmentation issues
On Mon, Apr 08, 2013 at 08:09:08PM -0400, Justin Lebar wrote: > > AIUI, on Windows the smallest block you can ask for with VirtualAlloc > > is 4 KiB. However, no more than one VirtualAlloc block can exist per > > 64 KiB chunk. So if you ask for 4 KiB you'll end up wasting the > > remaining 60 KiB of address space in the 64 KiB chunk. > > Awesome memory, Nick. > > MSDN seems to confirm this. > > "The second parameter [to VirtualAlloc] indicates the range of > addresses the function should allocate. This value can be anywhere > from one page to 2 GB in size, but VirtualAlloc is actually > constrained to a smaller range than that. The minimum size that can be > reserved is 64K, and the maximum that can be reserved is the largest > contiguous range of free addresses in the process. Requesting one page > of reserved addresses results in a 64K address range." > > http://msdn.microsoft.com/en-us/library/ms810627.aspx > > We have the ability to intercept VirtualAlloc calls on Windows, so > assuming that works for these particular VirtualAlloc calls (it > should?) perhaps we can take backtraces and write them to a file. We're already intercepting VirtualAlloc in xpcom/base/AvailableMemoryTracker.cpp Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Virtual Memory fragmentation issues
On 4/8/2013 7:46 PM, Benjamin Smedberg wrote: See bug 875030 for information that led me along this path. In this case, the user has plenty of memory (according to Windows) and is still failing to allocate moderate-size graphics buffers (1-2MB). This has very similar symptoms to a bunch of other crashes that we've been seeing in low volume over the past few years. This has become more urgent because low-memory crashes often fail to report good crash reports (because taking a crash reporting minidump requires some allocation on Windows). bug 857030 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What does BC stand for?
On Thursday, March 21, 2013 10:21:09 AM UTC+8, RyanVM wrote: > On 3/14/2013 7:14 PM, allencb...@gmail.com wrote: > > > Any idea what the tentative timeframe of rolling this out? in firefox 23 ? > > > > > > > The goal is Firefox 23, yes. Am I right to assume that the XULrunner 23 daily build includes BC? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebAPI team plans
On 2013-04-06 11:24 AM, David Bruant wrote: Le 03/04/2013 22:12, Andrew Overholt a écrit : Yesterday a number of people discussed future plans for the WebAPI team. Our discussion resulted in the ideas and comments that are on this wiki page: https://wiki.mozilla.org/WebAPI/PlannedWork There is a little item near the end, "tests". What is planned exactly as far as tests are concerned? Getting more test coverage I believe. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Virtual Memory fragmentation issues
> AIUI, on Windows the smallest block you can ask for with VirtualAlloc > is 4 KiB. However, no more than one VirtualAlloc block can exist per > 64 KiB chunk. So if you ask for 4 KiB you'll end up wasting the > remaining 60 KiB of address space in the 64 KiB chunk. Awesome memory, Nick. MSDN seems to confirm this. "The second parameter [to VirtualAlloc] indicates the range of addresses the function should allocate. This value can be anywhere from one page to 2 GB in size, but VirtualAlloc is actually constrained to a smaller range than that. The minimum size that can be reserved is 64K, and the maximum that can be reserved is the largest contiguous range of free addresses in the process. Requesting one page of reserved addresses results in a 64K address range." http://msdn.microsoft.com/en-us/library/ms810627.aspx We have the ability to intercept VirtualAlloc calls on Windows, so assuming that works for these particular VirtualAlloc calls (it should?) perhaps we can take backtraces and write them to a file. On Mon, Apr 8, 2013 at 7:57 PM, Nicholas Nethercote wrote: > On Mon, Apr 8, 2013 at 4:46 PM, Benjamin Smedberg > wrote: >> >> 1) early in the memory info, there appears to be a common pattern of a >> committed block and then 15 free blocks. > > AIUI, on Windows the smallest block you can ask for with VirtualAlloc > is 4 KiB. However, no more than one VirtualAlloc block can exist per > 64 KiB chunk. So if you ask for 4 KiB you'll end up wasting the > remaining 60 KiB of address space in the 64 KiB chunk. > > Assuming I'm right about this (I'm fairly certain, but not 100%), it > sounds like some code (be it Mozilla or driver code) is > VirtualAlloc'ing lots of 4 KiB blocks, and thus wasting lots of > address space. > > Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Virtual Memory fragmentation issues
On Mon, Apr 8, 2013 at 4:46 PM, Benjamin Smedberg wrote: > > 1) early in the memory info, there appears to be a common pattern of a > committed block and then 15 free blocks. AIUI, on Windows the smallest block you can ask for with VirtualAlloc is 4 KiB. However, no more than one VirtualAlloc block can exist per 64 KiB chunk. So if you ask for 4 KiB you'll end up wasting the remaining 60 KiB of address space in the 64 KiB chunk. Assuming I'm right about this (I'm fairly certain, but not 100%), it sounds like some code (be it Mozilla or driver code) is VirtualAlloc'ing lots of 4 KiB blocks, and thus wasting lots of address space. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Virtual Memory fragmentation issues
On 4/8/2013 7:46 PM, Benjamin Smedberg wrote: In this case, the crash report shows "Available Virtual Memory" as 303558656, but in fact the largest contiguous block of available VM is 64k. Correct, I had wrong math. The largest block available is about 3MB, and the allocation being requested from graphics is 9MB. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Virtual Memory fragmentation issues
In stability-land we're starting to see some "interesting" problems relating to virtual memory usage in Firefox on Windows. See bug 875030 for information that led me along this path. In this case, the user has plenty of memory (according to Windows) and is still failing to allocate moderate-size graphics buffers (1-2MB). This has very similar symptoms to a bunch of other crashes that we've been seeing in low volume over the past few years. This has become more urgent because low-memory crashes often fail to report good crash reports (because taking a crash reporting minidump requires some allocation on Windows). Fortunately on Windows, the minidump contains complete information about the access and commit state of every process page. I have created a visualizer for this information here: http://people.mozilla.com/~bsmedberg/graphical-minidump-memoryinfo/ In this case, the crash report shows "Available Virtual Memory" as 303558656, but in fact the largest contiguous block of available VM is 64k. There are a couple problems here: 1) early in the memory info, there appears to be a common pattern of a committed block and then 15 free blocks. 2) later on, there appear to be a large number of 8.7MB allocated blocks which are mapped memory. The minidump does not appear tell me any more about the mapping, whether it is a file mapping, or named or anonymous shared memory. 3) The user (who can reproduce this reliably) reports that disabling the nviia graphics card and switching to integrated graphics on their laptop solves the issue. I think we need to urgently solve the most common crash issue by making more graphics allocations fallible (bug 829954), and I think Bas is working on that. But that's only going to cause Firefox behave weirdly instead of crashing. Either our code or the ATI driver is leaking mapped memory references in a way that chews up VM space without actually using memory. We need to figure out why and fix our work around the problem. I'm hoping that one of you on the "To" of this email may be able to help figure out a way to either patch Firefox or run an external debugging tool which can help record information about the stacks when these mappings are typically created and destroyed, and help create a detailed understanding of the problem so that we can either fix our code or hand the problem to the nvidia developers with the most reproducible/detailed report possible. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing gcc 4.5 as the default Linux compiler?
Gabriele Svelto schrieb: On 05/04/2013 01:49, Robert Kaiser wrote: Though its feature set seems to be quite helpful for us: http://lwn.net/Articles/543570/ Makes me think that we should at least experiment with it to make sure are issues we have with it will be fixed in a .1 or so and we'll be able to use that. I've got a build of gcc-4.8.0 on Linux along with all the previous major versions which I often use for testing. I'm trying a full build now; is there any specific test that would be worth doing? A full run of the unit tests maybe? Or even some performance testing on a relevant benchmark? I think all of that would be interesting. Not sure how to see results from the Graphite or PRE changes mentioned in that article. Also not sure what the DWARF changes actually mean for us. In terms of perf, what would be interesting would be gcc 4.5 vs. 4.8 with the same options we use to compile Linux Nightly builds. But I'm just guessing there. People like e.g. Mike Hommey probably know more on what would be interesting there. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebP support
I assume all this data/reasoning will be posted in the bug. People just didn't get around to it yet. The idea was to use the bug to discuss the issue. There is definitely no decision yet to ship, just a decision to take a look at some additional data point someone raised. Andreas Sent from Mobile. On Apr 8, 2013, at 9:55, Ralph Giles wrote: > On 13-04-08 4:06 AM, Jeff Muizelaar wrote: >> No decision has been made yet. We are still evaluating the format. > > I think the concern is that none of that re-evaluation has been on a > public list or bug I've seen. Can you clarify what Andreas meant by, > "new data that shows that WebP has valid use cases and advantages" in > https://bugzilla.mozilla.org/show_bug.cgi?id=600919#c185 ? > > -r > > ___ > 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
Re: WebP support
On 13-04-08 10:02 AM, Jeff Muizelaar wrote: > Sure. Everything.me was seeing large gains when using lossy image compression > with an alpha channel compared to png. This isn't a surprise but it's a use > case that's not well supported by the current image formats we support. At least not since we removed jng support? :) Thanks for clarifying! -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebP support
Sure. Everything.me was seeing large gains when using lossy image compression with an alpha channel compared to png. This isn't a surprise but it's a use case that's not well supported by the current image formats we support. -Jeff On 2013-04-08, at 12:53 PM, Ralph Giles wrote: > On 13-04-08 4:06 AM, Jeff Muizelaar wrote: >> No decision has been made yet. We are still evaluating the format. > > I think the concern is that none of that re-evaluation has been on a > public list or bug I've seen. Can you clarify what Andreas meant by, > "new data that shows that WebP has valid use cases and advantages" in > https://bugzilla.mozilla.org/show_bug.cgi?id=600919#c185 ? > > -r > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebP support
On 13-04-08 4:06 AM, Jeff Muizelaar wrote: > No decision has been made yet. We are still evaluating the format. I think the concern is that none of that re-evaluation has been on a public list or bug I've seen. Can you clarify what Andreas meant by, "new data that shows that WebP has valid use cases and advantages" in https://bugzilla.mozilla.org/show_bug.cgi?id=600919#c185 ? -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XULRunner support for Android
I am able to execute some pieces of a XULRunner-based app fine with B2G. I simply took B2G work binary that Romaxa did for the Raspberry PI. Do you need XUL widgets or you just want to call your Chrome URL from B2G Gecko app? m On Mon, Apr 8, 2013 at 1:06 PM, Emmanuel Engelhart wrote: > Le 08/04/2013 15:32, stathis.androni...@gmail.com a écrit : >> I have the following question: >> >> Is there any way to port an application from Xulrunner to Android? >> or which is the propper way to port a xulrunner app to android. >> >> Any help would be appreciated. Thanks! > > Xulrunner is not ported to Android. I think it never will. I have > invested many hours trying to hack the code of firefox/xulrunner without > success. I still think this is somehow possible but this need a pretty > good knowledge of Mozilla code source. Our solution was to rewrite a > native android UI and deal with our c++ code using JNI. > > Kelson > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- www.telasocial.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XULRunner support for Android
Le 08/04/2013 15:32, stathis.androni...@gmail.com a écrit : > I have the following question: > > Is there any way to port an application from Xulrunner to Android? > or which is the propper way to port a xulrunner app to android. > > Any help would be appreciated. Thanks! Xulrunner is not ported to Android. I think it never will. I have invested many hours trying to hack the code of firefox/xulrunner without success. I still think this is somehow possible but this need a pretty good knowledge of Mozilla code source. Our solution was to rewrite a native android UI and deal with our c++ code using JNI. Kelson ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DOM Bindings Meeting - Monday @ 12:30 PM PDT
Our (ostensibly) weekly DOM bindings meetings continue on Monday April 8th at 12:30 PM PDT. Meeting details: * Monday, April 8, 2013, 12:30 PM PDT (9:30 PM CEST) * Conference room 7-N, San Francisco office, 7th floor. * Dial-in Info: - Vidyo room: SFO-7N - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 95704 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
XULRunner support for Android
I have the following question: Is there any way to port an application from Xulrunner to Android? or which is the propper way to port a xulrunner app to android. Any help would be appreciated. Thanks! Regards Stathis ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebP support
No decision has been made yet. We are still evaluating the format. -Jeff On 2013-04-08, at 5:09 AM, David Bruant wrote: > Hi, > > (I'm not 100% sure this is the proper mailing list to ask this question, but > I can't think of a more relevant mailing-list at this time. Please forward if > inappropriate) > > After a long period of reluctance, Mozilla is deciding to implement WebP > [1][2]. The only explanation I have been able to find was: > "We decided to re-open this based on new data that shows that WebP has valid > use cases and advantages." > Is there a longer explanation somewhere? If possible one where Mozilla > previous concerns are addressed. > > Thanks, > > David > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=600919#c185 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=856375 > ___ > 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
WebP support
Hi, (I'm not 100% sure this is the proper mailing list to ask this question, but I can't think of a more relevant mailing-list at this time. Please forward if inappropriate) After a long period of reluctance, Mozilla is deciding to implement WebP [1][2]. The only explanation I have been able to find was: "We decided to re-open this based on new data that shows that WebP has valid use cases and advantages." Is there a longer explanation somewhere? If possible one where Mozilla previous concerns are addressed. Thanks, David [1] https://bugzilla.mozilla.org/show_bug.cgi?id=600919#c185 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=856375 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
