On Thu, Apr 25, 2013 at 7:41 AM, Caspy7 wrote:
> I'm not a developer and so apologize if my understanding is oversimplified
> or naive.
> I had been under the impression that C++ (previously) was not being used
> at all, apart from Gecko itself, for security and stability reasons.
> Perhaps I am
I'm not a developer and so apologize if my understanding is oversimplified or
naive.
I had been under the impression that C++ (previously) was not being used at
all, apart from Gecko itself, for security and stability reasons. Perhaps I am
mistaken or simply misunderstand the structures discuss
On Monday, April 22, 2013 7:28:30 AM UTC-7, Justin Lebar wrote:
>
> The issue isn't compilation of code; that doesn't stick out in the
> memory reports. The issue seems to be mostly the overhead of the JS
> engine for each file (even if the file stores very little data, as
> BrowserElementParent
To close the loop on this thread, the consensus here seems to be that
1. We should continue to make JS slimmer. This is a high priority for
B2G even setting aside the memory consumption of B2G's chrome JS,
since of course B2G runs plenty of content JS.
The memory profile of B2G is different from
On Mon, Apr 22, 2013 at 6:35 PM, Justin Dolske wrote:
>
> That said, I think it's critically important that we're working to make JS a
> acceptable -- nay, _excellent_ -- language/runtime for application
> development for the long run. We can't tell a credible story about why
> people should write
On 4/21/13 4:51 PM, Justin Lebar wrote:
What I'd like to come out of this thread is a consensus one way or another as
to whether we continue along our current path of writing many features that are
enabled on B2G in JS, or whether we change course.
First -- B2G should clearly do whatever it ne
On 23/04/13 24:18 , Nicolas B. Pierron wrote:
On 04/22/2013 07:53 AM, Justin Lebar wrote:
This is the wifi worker. I think "script-sources" is code. Note that
fragmentation (unused-arenas) is way too high, but even despite this
the worker uses too much memory.
2.38 MB (05.13%) -- worker(reso
On 04/22/2013 07:53 AM, Justin Lebar wrote:
This is the wifi worker. I think "script-sources" is code. Note that
fragmentation (unused-arenas) is way too high, but even despite this
the worker uses too much memory.
2.38 MB (05.13%) -- worker(resource://gre/modules/wifi_worker.js, 0x45584800)
On 4/22/13 5:22 PM, Jeff Muizelaar wrote:
I don't know if there's anything surprising here. Calling into JS from C++ goes
through xpconnect which is a long standing slowness.
_That_ we can try to fix by converting to JS-implemented WebIDL. Right
now that performs about the same, but we know
On 2013-04-22, at 3:44 PM, Terrence Cole wrote:
> On 04/22/2013 12:12 PM, Jeff Muizelaar wrote:
>> On 2013-04-22, at 2:15 PM, Bill McCloskey wrote:
>>
>>> I can't agree with you more, Justin. I think Boris is right that we should
>>> make these decisions on a case-by-case basis. But in the case
On Mon, Apr 22, 2013 at 9:48 PM, Justin Lebar wrote:
> > This is all great stuff, but as mentioned elsewhere, B2G branched at
> > version 18 and so they need improvements that that can land quickly on
> > the relevant branches.
>
I understand that (but should certainly have made it more clear).
On Mon, Apr 22, 2013 at 1:32 PM, Nicholas Nethercote
wrote:
>
> - Looking at the merged.json data: the system principal compartment
> merging is happening on the main process, but doesn't appear to be
> happening on all the other processes: Homescreen, Usage,
> (Preallocated app).
I filed https
> This is all great stuff, but as mentioned elsewhere, B2G branched at
> version 18 and so they need improvements that that can land quickly on
> the relevant branches.
Well, to be clear, it would be great if we could land some
improvements for v1.1 (which is based off version 18), but we're
locki
On Mon, Apr 22, 2013 at 1:25 PM, Till Schneidereit
wrote:
> There are a few things we're working on in SpiderMonkey that should improve
> this situation quite a bit:
>
> ...generational GC...
>
> making bytecode generation lazy...
> ...re-lazyfication of JSScripts...
> ...lazy cloning of JSScripts
> There are a few things we're working on in SpiderMonkey that should improve
> this situation quite a bit:
Thanks, but I again need to emphasize that these are large, long-term
plans. Terrence tells me that GGC is planned for "sometime this
year". Lazy bytecode generation has been on the roadma
Some comments on this whole thread:
- I'm very sympathetic to Justin's concerns. 120 MiB is not much
memory. While it's (somewhat) ok to kill apps that are using too much
memory, that doesn't work with the main B2G process, and I've been
CC'd on enough "the B2G main process is using too much mem
There are a few things we're working on in SpiderMonkey that should improve
this situation quite a bit:
Terrence already mentioned generational GC, which certainly is the largest
piece by far. Getting rid of all or almost all memory lost to fragmentation
makes the tradeoff a considerably different
On 04/22/2013 12:12 PM, Jeff Muizelaar wrote:
> On 2013-04-22, at 2:15 PM, Bill McCloskey wrote:
>
>> I can't agree with you more, Justin. I think Boris is right that we should
>> make these decisions on a case-by-case basis. But in the case of these
>> workers, it seems clear that converting the
On 2013-04-22, at 2:15 PM, Bill McCloskey wrote:
> I can't agree with you more, Justin. I think Boris is right that we should
> make these decisions on a case-by-case basis. But in the case of these
> workers, it seems clear that converting them to C++ is the way to go,
> assuming we have the
On 04/22/2013 11:07 AM, Justin Lebar wrote:
>> I can't really agree or disagree without knowing why they use "too much"
>> memory.
> At the risk of sounding like a broken record, it's all in the memory
> reports. You probably understand this data better than I do. Extract
> and load in about:memo
Mike Hommey wrote:
On Sun, Apr 21, 2013 at 07:51:18PM -0400, Justin Lebar wrote:
I think we should consider using much less JS in the parts of Gecko that are
used in B2G. I'd like us to consider writing new modules in C++ where
possible, and I'd like us to consider rewriting existing modules
I can't agree with you more, Justin. I think Boris is right that we
should make these decisions on a case-by-case basis. But in the case of
these workers, it seems clear that converting them to C++ is the way to
go, assuming we have the resources to do so.
-Bill
On 04/22/2013 11:07 AM, Justin
> I can't really agree or disagree without knowing why they use "too much"
> memory.
At the risk of sounding like a broken record, it's all in the memory
reports. You probably understand this data better than I do. Extract
and load in about:memory (button is at the bottom).
http://people.mozill
On 04/21/2013 04:51 PM, Justin Lebar wrote:
> I think we should consider using much less JS in the parts of Gecko that are
> used in B2G. I'd like us to consider writing new modules in C++ where
> possible, and I'd like us to consider rewriting existing modules in C++.
>
> I'm only proposing a ch
> So to the extent that b2g is in a "not enough hands" situation, implementing
> in JS
> makes sense.
I don't feel like b2g is in this position. We don't have a lot of
Gecko hackers with 2+ years of experience, but we do have a lot of
hackers. Whether or not we have a lot of C++ versus JS hacke
> How about making the JS engine use jemalloc instead of its own
> allocator? Does anything actually rely on the arenas being independent
> at the paging level?
My understanding, which may be wrong, is that the JS engine needs to
be able to quickly map an object's address to a compartment. They d
On Mon, Apr 22, 2013 at 10:53:40AM -0400, Justin Lebar wrote:
> > How about pre-compiling JS in JITed form?
>
> While significant, it seems that memory used for script source isn't
> the biggest offender.
>
> Full details are in the about:memory reports,
>
> http://people.mozilla.org/~jlebar/dow
> How about pre-compiling JS in JITed form?
While significant, it seems that memory used for script source isn't
the biggest offender.
Full details are in the about:memory reports,
http://people.mozilla.org/~jlebar/downloads/merged.json.xz
http://people.mozilla.org/~jlebar/downloads/unmerged.jso
On 4/21/13 7:51 PM, Justin Lebar wrote:
Since most of these features implemented in JS seem to be DOM features, I'm
particularly interested in the opinions of the DOM folks.
Opinions differ. ;)
I think for DOM features that are not invoked on most pages,
implementing them in JS seems like a
On Sun, Apr 21, 2013 at 07:51:18PM -0400, Justin Lebar wrote:
> I think we should consider using much less JS in the parts of Gecko that are
> used in B2G. I'd like us to consider writing new modules in C++ where
> possible, and I'd like us to consider rewriting existing modules in C++.
>
> I'm o
> I think I would like to hear from the JS team on reducing memory use of JS and
> disabling any compilation for infrequently running code before we give
> up on it.
The issue isn't compilation of code; that doesn't stick out in the
memory reports. The issue seems to be mostly the overhead of the
The things on Justin's list do not appear to be infrequently running code.
Wifi, RIL, Apps, mozbrowser, etc are going to be running all the time.
- Kyle
On Mon, Apr 22, 2013 at 7:11 AM, Andreas Gal wrote:
> JS is a big advantage for rapid implementation of features and it's
> easier to avoid e
JS is a big advantage for rapid implementation of features and it's
easier to avoid exploitable mistakes. Also, in many cases JS code
(bytecode, not data) should be slimmer than C++. Using JS for
infrequently executing code should be a memory win. I think I would
like to hear from the JS team on re
Of course attachments don't work great on newsgroups. I've uploaded
the about:memory dumps I tried to attach to people.m.o:
http://people.mozilla.org/~jlebar/downloads/merged.json.xz
http://people.mozilla.org/~jlebar/downloads/unmerged.json.xz
On Sun, Apr 21, 2013 at 7:51 PM, Justin Lebar wrote
34 matches
Mail list logo
