On Tue, Mar 04, 2014 at 09:48:33AM +0200, Henri Sivonen wrote:
On Fri, Feb 28, 2014 at 8:09 PM, L. David Baron dba...@dbaron.org wrote:
In other words, whenever you have a pointer in a static data
structure pointing to some other data, that pointer needs to get
fixed up when the library
On Mon, Mar 3, 2014 at 11:48 PM, Henri Sivonen hsivo...@hsivonen.fi wrote:
Are static atoms and the HTML parser's pre-interned element name and
attribute name objects that are on the heap shared between processes
under Nuwa already? I.e. is the heap cloned with copy-on-write
sharing? On the
On Fri, Feb 28, 2014 at 8:09 PM, L. David Baron dba...@dbaron.org wrote:
In other words, whenever you have a pointer in a static data
structure pointing to some other data, that pointer needs to get
fixed up when the library loads, which makes the memory that pointer
is in less likely to be
Henri Sivonen wrote:
Any chance static atoms could reside as plain old static C data structures in
the data segment of libxul.so instead of being heap-allocated?
At least under MSVC, they have vtables, so they need to be constructed,
so they're not static. Note that their string storage is
On Fri, Feb 28, 2014 at 1:04 PM, Neil n...@parkwaycc.co.uk wrote:
At least under MSVC, they have vtables, so they need to be constructed, so
they're not static.
So structs that inherit at least one virtual method can't be plain old
C data? That surprises me. And we still don't want to give the
http://en.wikipedia.org/wiki/Plain_Old_Data_Structures
confirms that POD can't have a vptr :-)
Benoit
2014-02-28 7:39 GMT-05:00 Henri Sivonen hsivo...@hsivonen.fi:
On Fri, Feb 28, 2014 at 1:04 PM, Neil n...@parkwaycc.co.uk wrote:
At least under MSVC, they have vtables, so they need to be
- Original Message -
http://en.wikipedia.org/wiki/Plain_Old_Data_Structures
confirms that POD can't have a vptr :-)
Just because it's not POD in the language doesn't mean that it necessarily
requires a static initializer in all implementations:
class Interface {
public:
On Fri, Feb 28, 2014 at 05:59:13AM -0800, Nathan Froyd wrote:
- Original Message -
http://en.wikipedia.org/wiki/Plain_Old_Data_Structures
confirms that POD can't have a vptr :-)
class Interface {
public:
constexpr Interface() {}
virtual int f() = 0;
};
class
Neil wrote:
Henri Sivonen wrote:
Any chance static atoms could reside as plain old static C data
structures in the data segment of libxul.so instead of being
heap-allocated?
At least under MSVC, they have vtables, so they need to be
constructed, so they're not static. Note that their
On 2/28/14 12:26 PM, Neil wrote:
Perhaps we could probably use string buffers directly as atoms.
Atoms have various info string buffers don't (like the hashcode).
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Friday 2014-02-28 11:04 +, Neil wrote:
Henri Sivonen wrote:
Any chance static atoms could reside as plain old static C data structures
in the data segment of libxul.so instead of being heap-allocated?
At least under MSVC, they have vtables, so they need to be
constructed, so they're
On Fri, Feb 21, 2014 at 11:38 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
We now live in a memory-constrained world. By we, I mean anyone
working on Mozilla platform code.
I realize that .so size matters much less than per-process
heap-allocated stuff, but still:
On the i18n front
On Tue, Feb 25, 2014 at 8:18 PM, Mike Hommey m...@glandium.org wrote:
I never understood why we need those jobs to be builds. Why not turn
--enable-valgrind on m-c builds, and run valgrind as a test job?
--disable-jemalloc is needed as well.
That shouldn't be needed anymore with
On 2014-02-26, 8:44 AM, Nicholas Nethercote wrote:
On Tue, Feb 25, 2014 at 8:18 PM, Mike Hommey m...@glandium.org wrote:
I never understood why we need those jobs to be builds. Why not turn
--enable-valgrind on m-c builds, and run valgrind as a test job?
--disable-jemalloc is needed as well.
Splitting the valgrind tests up and running them separately as test jobs
in TBPL is definitely something the A*Team can help with. I've filed
bug 977240 for this.
Jonathan
On 2/25/14 7:25 PM, Nicholas Nethercote wrote:
On Tue, Feb 25, 2014 at 2:32 PM, Mike Hommey m...@glandium.org wrote:
I
: Nicholas Nethercote n.netherc...@gmail.com
To: Ehsan Akhgari ehsan.akhg...@gmail.com
Cc: dev-platform dev-platform@lists.mozilla.org
Sent: Monday, February 24, 2014 7:08:31 PM
Subject: Re: We live in a memory-constrained world
On Mon, Feb 24, 2014 at 6:50 PM, Ehsan Akhgari ehsan.akhg
On 2/24/2014, 10:08 PM, Nicholas Nethercote wrote:
On Mon, Feb 24, 2014 at 6:50 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Nick, do we run any kind of automated leak checking through valgrind? I
found bug 976363 today, it's something that any automated leak detection
tool should be able
On Tue, Feb 25, 2014 at 12:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
The Valgrind test job does leak checking, and it's recently caught
some leaks and caused the offending patches to be backed out. However,
the test coverage is pretty meagre, and it's desktop only so can't
detect
On 2014-02-25, 3:53 PM, Nicholas Nethercote wrote:
On Tue, Feb 25, 2014 at 12:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
The Valgrind test job does leak checking, and it's recently caught
some leaks and caused the offending patches to be backed out. However,
the test coverage is
On Tue, Feb 25, 2014 at 1:10 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
How much slower is a valgrind run of let's say mochitest-1 on a test slave?
I don't think that we can run many interesting tests on valgrind on the
build machine (and the PGO test set is *really* old and doesn't
On Tue, Feb 25, 2014 at 2:32 PM, Mike Hommey m...@glandium.org wrote:
I never understood why we need those jobs to be builds. Why not turn
--enable-valgrind on m-c builds, and run valgrind as a test job?
--disable-jemalloc is needed as well.
As for the structure... I just took what already
On 2/22/14, 1:39 PM, Nicholas Nethercote wrote:
On Sat, Feb 22, 2014 at 11:22 PM, Andreas Gal andreas@gmail.com wrote:
So, I'm wondering how much effort we should put in reducing the number
of ChromeWorkers.
We should continue to use JS in Chrome where it makes sense. Its often easier
On 2/21/2014 5:40 PM, Brian Smith wrote:
On Fri, Feb 21, 2014 at 1:38 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
Optimizations that wouldn't have been worthwhile in the desktop-only
days are now worthwhile. For example, an optimization that saves 100
KiB of memory per process is
On 02/21/2014 02:57 PM, Nicholas Nethercote wrote:
On Sat, Feb 22, 2014 at 9:40 AM, Brian Smith br...@briansmith.org wrote:
How worthwhile is it to cut 100KiB from the parent process?
We don't have a fixed memory budget per se. If it's easy and doesn't
have bad side-effects, do it.
.
We live in a memory-constrained world.
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform
On Mon, Feb 24, 2014 at 6:50 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Nick, do we run any kind of automated leak checking through valgrind? I
found bug 976363 today, it's something that any automated leak detection
tool should be able to catch.
The Valgrind test job does leak
- Original Message -
The Valgrind test job does leak checking, and it's recently caught
some leaks and caused the offending patches to be backed out. However,
the test coverage is pretty meagre, and it's desktop only so can't
detect leaks in IPC code.
I believe the ASan builds also
On Fri, Feb 21, 2014 at 9:56 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
If your data is read-only after the point at which Nuwa forks the
process (which is once things are mostly loaded but before we load the
app) then generally yes. It's copy-on-write at page granularity of
On Sat, Feb 22, 2014 at 11:22 PM, Andreas Gal andreas@gmail.com wrote:
So, I'm wondering how much effort we should put in reducing the number
of ChromeWorkers.
We should continue to use JS in Chrome where it makes sense. Its often easier
and faster to write some functionality in JS (and
On 02/21/2014 01:38 PM, Nicholas Nethercote wrote:
Greetings,
We now live in a memory-constrained world. By we, I mean anyone
working on Mozilla platform code. When desktop Firefox was our only
product, this wasn't especially true -- bad leaks and the like were a
problem, sure, but ordinary
30 matches
Mail list logo
