Last year I claimed that Servo had a number of huge stacks, as
reported by /proc//smaps. It turns out that these measurements
are inaccurate -- if a non-stack mapping gets placed next to a stack
mapping, the kernel merges them and the merged segment is marked as a
stack. I've confirmed this happens
On Jul 11, 2014, at 2:15 PM, Patrick Walton wrote:
> On 7/11/14 12:54 PM, Cameron Zwarich wrote:
>> These giant numbers aren’t too surprising, since LLVM isn’t that
>> great at optimizing stack space. Is Rust inserting the lifetime.start
>> and lifetime.end markers?
>>
>> http://llvm.org/docs/La
On 7/11/14 12:54 PM, Cameron Zwarich wrote:
These giant numbers aren’t too surprising, since LLVM isn’t that
great at optimizing stack space. Is Rust inserting the lifetime.start
and lifetime.end markers?
http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic
Use of lifetime markers is
On Jul 11, 2014, at 12:04 PM, Brian Anderson wrote:
> Rust does have 2MB stacks by default. These giant numbers are surprising.
These giant numbers aren’t too surprising, since LLVM isn’t that great at
optimizing stack space. Is Rust inserting the lifetime.start and lifetime.end
markers?
http
- Original Message -
> Rust does have 2MB stacks by default. These giant numbers are surprising.
In Gecko, we've found that almost anytime we start measuring something, we find
something surprising. ;)
Andrew
___
dev-servo mailing list
dev-se
On 07/10/2014 11:11 PM, Nicholas Nethercote wrote:
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
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
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 it
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.
Hi
I'm able to reproduce, and I think I've found the problem. It is unrelated to
quadtree.rs, which is originally what I suspected.
Using the OpenGL profiler, I can see that whenever Servo draws a tile, it
allocates a new GL_R8 texture of size 1024x2048. I think Patrick mentioned that
Skia may be
10 matches
Mail list logo
