[dev-servo] Fwd: Servo on Android

2014-07-10 Thread Simon Sapin 

Hi all,

Can someone help this person with Servo on Android? Please keep them in 
CC as they’re probably not subscribed to the list.


Thanks,
--
Simon Sapin

On 10/07/14 14:39, Cristian Silaghi wrote:

Can you share with me one recent build of Servo for Android? I want to
test it on my phone, but it seems my distro is not able to build one
(I'm using BBQLinux, based on Arch Linux). So can you send me
"ServoAndroid-debug.apk" ? :)

P.S.: It would be useful in the future to have automatic machine which
can build Servo for Android or a place where devs can share those builds! :)

Best Regards,
Cristian Silaghi

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Fwd: Servo on Android

2014-07-10 Thread Matt Brubeck 

On 10/07/14 14:39, Cristian Silaghi wrote:

Can you share with me one recent build of Servo for Android? I want to
test it on my phone, but it seems my distro is not able to build one
(I'm using BBQLinux, based on Arch Linux). So can you send me
"ServoAndroid-debug.apk" ? :)

Here's my local Android build from yesterday, signed with my debug key:
http://people.mozilla.org/~mbrubeck/ServoAndroid-debug.apk

It will try to load a file from this path on the device: 
/mnt/sdcard/html/about-mozilla.html


On my device at least, it runs and renders the background color of my 
test page but fails to render any text.



P.S.: It would be useful in the future to have automatic machine which
can build Servo for Android or a place where devs can share those 
builds! :)
Yes -- we (well, Lars) are actively working on adding an Android build 
to our Travis CI automation.

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Servo memory usage

2014-07-10 Thread Nicholas Nethercote 
Hi,

With https://github.com/mozilla/servo/pull/2803 applied, the -m option
now gives some measurements from jemalloc. Here's example output after
starting up and viewing about:mozilla on my Linux box.

_category_  : _size (MiB)_
vsize   :  1414.54
resident:88.50
heap-allocated  : 8.53
heap-active : 8.76
heap-mapped :80.00

The heap-mapped number isn't so important -- it appears to map a big
chunk but not actually touch most of it, so it's only using address
space. The heap-allocated and heap-active numbers are more important,
and indicate that the jemalloc heap -- which is used by the Rust code
-- is small.

So there must be a decent chunk of memory being used by third-party
libraries, which don't (AFAIK) use jemalloc, but instead use the
system malloc. I ran Massif (a Valgrind-based memory profiler) to
measure this usage, and I've attached the results. In short, there's
about 30 MiB in the profile, and over 2% of it is the GL driver
allocating memory for GL contexts under glfwCreateWindow(). It's hard
to get good measurements of these allocations without invasive
instrumentation techniques, alas. (I've hit exactly the same issue
recently with Firefox, sigh:
https://blog.mozilla.org/nnethercote/2014/07/07/measuring-memory-used-by-third-party-code/)

There is also some Servo stuff in that output: some font stuff and
some SleeperThread stuff. I wasn't expecting these in this output,
since they are jemalloc allocations that Massif shouldn't be able to
see, but it turns out that jemalloc has some Valgrind annotations that
tell Massif about the allocations. So this profile is actually a mix
of jemalloc and the system malloc. I'm not sure how good the
annotations are, and thus whether the jemalloc heap coverage is
complete or not.

That still leaves a decent chunk of the 88.5 MiB of resident
unaccounted for. So I did some grovelling through /proc//smaps.
As well as the expected stuff (various sizeable anonymous mmaps, and
various libraries, most of which were shared with multiple other
processes), here were the most notable measurements:

- /home/njn/moz/servo/build/servo 6260 kB
- [stack:28150] 1136 kB
- [stack:28145] 6144 kB
- [stack:28144] 2048 kB
- [stack:28141] 8192 kB
- [stack:28139] 7944 kB
- [stack:28136] 5120 kB

The |servo| process isn't surprising, but those are some big stacks.
Much bigger than I'm used to seeing with C or C++ programs. (There
were a few more stacks in the 100s of kBs that I didn't bother
listing.)

So, overall, of that 88.5 MiB resident, the rough breakdown is this:

- jemalloc (Rust) heap: 9 MiB
- gl driver: 23 MiB
- stacks: 32 MiB
- servo executable: 6 MiB
- various libs: ~5 MiB
- not sure: ~12 MiB

Does Rust have any stack-measuring capabilities?

Nick
49.60% (15,745,040B)
- 0x12E135E1: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12F6F938: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12F0B302: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x6CA2903: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
- 0x6C7AA40: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
- 0x10D569D: _glfwCreateContext (in /home/njn/moz/servo/build/servo)
- 0x10DBD1B: _glfwPlatformCreateWindow (in /home/njn/moz/servo/build/servo)
- 0x10D37AC: glfwCreateWindow (in /home/njn/moz/servo/build/servo)

08.58% (2,722,848B)
- 0x12D471F4: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12E03086: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12E556F6: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12F6F96B: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12F0B302: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x6CA2903: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
- 0x6C7AA40: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
- 0x10D569D: _glfwCreateContext (in /home/njn/moz/servo/build/servo)
- 0x10DBD1B: _glfwPlatformCreateWindow (in /home/njn/moz/servo/build/servo)
- 0x10D37AC: glfwCreateWindow (in /home/njn/moz/servo/build/servo)

06.75% (2,144,284B)
- in 489 places, all below massif's threshold (01.00%)

05.94% (1,884,729B)
- 0x12F0975C: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12E7D63B: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12F9D36A: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12F9D7DC: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12F7010E: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x12F0B302: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
- 0x6CA2903: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
- 0x6C7AA40: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
- 0x10D569D: _glfwCreateContext (in /home/njn/moz/servo/build/servo)
- 0x10DBD1B: _glfwPlatformCreateWindow (in /home/njn/moz/servo/build/servo)
- 0x10D37AC: glfwCreateWindow (in /home/njn/moz/servo/build/servo)

03.30% (1,048,576B)
- 0xC5B099: je_rallocx (in /home/njn/moz/servo/build/servo)
- 0x6B3039: vec::alloc_or_reallo

Re: [dev-servo] Servo memory usage

2014-07-10 Thread Patrick Walton 

On 7/10/14 9:46 PM, Nicholas Nethercote wrote:

Does Rust have any stack-measuring capabilities?


It doesn't; let's definitely file a Rust issue on that.

The reason why Rust stacks don't go through jemalloc and instead mmap 
directly is because of the desire to place guard pages, I believe.


Historically, Rust's large stacks were due to the fact that at the time 
stack growth was removed, rustc had worse codegen than it did today, 
resulting in frames with very large activation records. Coupled with the 
fact that rustc itself uses recursion heavily (probably too heavily), 
the easiest thing to do was to give tasks large stacks by default. 
Perhaps this decision should be revisited, as I think that it may well 
be the case that rustc is going to be the exception, not the rule.


You can tune the size of stack growth when spawning a Rust task. Servo 
could definitely use a stack size audit; I bet a ton of MBs can be 
shaved off with some tuning.


Patrick

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo memory usage

2014-07-10 Thread Nicholas Nethercote 
On Thu, Jul 10, 2014 at 10:34 PM, Patrick Walton  wrote:
>
> Historically, Rust's large stacks were due to the fact that at the time
> stack growth was removed, rustc had worse codegen than it did today,
> resulting in frames with very large activation records. Coupled with the
> fact that rustc itself uses recursion heavily (probably too heavily), the
> easiest thing to do was to give tasks large stacks by default. Perhaps this
> decision should be revisited, as I think that it may well be the case that
> rustc is going to be the exception, not the rule.
>
> You can tune the size of stack growth when spawning a Rust task. Servo could
> definitely use a stack size audit; I bet a ton of MBs can be shaved off with
> some tuning.

"Large default stack size" doesn't seem to explain it.

I'd guess that the default is 2 MiB, because there are quite a few
entries in smaps like this:

7f54091fe000-7f54093fe000 rw-p  00:00 0
  [stack:28143]
Size:   2048 kB
Rss:  12 kB
Pss:  12 kB

2 MiB has been allocated, but only a tiny amount has been touched and
is thus in RSS.

Here are the two biggest stacks:

7f540a70-7f540b80 rw-p  00:00 0
  [stack:28139]
Size:  17408 kB
Rss:7944 kB
Pss:7944 kB

7f540960-7f540a40 rw-p  00:00 0
  [stack:28141]
Size:  14336 kB
Rss:8192 kB
Pss:8192 kB

For both, |Rss| is big and |Size| (equivalent to vsize) is even bigger.

Nick
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo memory usage

2014-07-10 Thread Nicholas Nethercote 
On Thu, Jul 10, 2014 at 10:34 PM, Patrick Walton  wrote:
>>
>> Does Rust have any stack-measuring capabilities?
>
> It doesn't; let's definitely file a Rust issue on that.

I filed https://github.com/rust-lang/rust/issues/15600. I have no idea
how it would be implemented.

Nick
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo