On Fri, Oct 6, 2017 at 8:57 PM, Nicholas Nethercote wrote:
> Memory reporting as done for about:memory is quite different to the memory
> profiling done for devtools.
>
> Here's how memory reporting works in SpiderMonkey: we iterate over every
> cell in the GC heap, and measure any malloc'd thin
Memory reporting as done for about:memory is quite different to the memory
profiling done for devtools.
Here's how memory reporting works in SpiderMonkey: we iterate over every
cell in the GC heap, and measure any malloc'd things hanging of those
cells. That's it. It's not at all a standard GC typ
Hi Nick!
The combination of deriving traits and Rust's ownership model is great for
memory reporting, and this stuff is _so_ much nicer to define than the
equivalent about:memory measurements in Firefox.
But it doesn't play out as well in the presence of a GC: ownership is
muddied. The Arc/Rc iss
> Le 6 oct. 2017 à 07:58, Nicholas Nethercote a écrit :
>
> Not being able to use derive doesn't worry me, because it's just a
> convenience. I just looked through all the external crates that implement
> HeapSizeOf and hardly any are using derive.
Most don't use derive because they started dep
> Le 6 oct. 2017 à 03:27, Nicholas Nethercote a écrit :
>
> I see two options.
>
> - Overwrite the heapsize crate on crates.io with the malloc_size_of code. So
> the crate name wouldn't change, but the API would change significantly,
> and
> it would still be on crates.io. Then switch Servo o
On Fri, Oct 6, 2017 at 4:15 PM, Manish Goregaokar
wrote:
> If we do impls in the mallocsizeof crate is we can't make use of the custom
> derive functionality and have to manually write out impls (which in many
> cases won't be possible).
Not being able to use derive doesn't worry me, because it
On Fri, Oct 6, 2017 at 4:07 PM, Manish Goregaokar
wrote:
> I kinda feel like upgrading HeapSizeOf to have a generic second
trait-bound
> argument that we substitute MallocSizeOfOps as would be good.
What problem would that solve? I don't want to add unnecessary abstraction.
Nick
If we do impls in the mallocsizeof crate is we can't make use of the custom
derive functionality and have to manually write out impls (which in many
cases won't be possible).
So I'm not sure if we can completely get rid of the dependency problem.
-Manish Goregaokar
On Thu, Oct 5, 2017 at 10:11
On 06/10/2017 06:05, Nicholas Nethercote wrote:
If we went with the second option from my original mail (i.e. stop using
heapsize) then it would probably make sense to deprecate heapsize entirely,
stop those crates from depending on it, and implement the MallocSizeOf
trait for those crates' types
> or it could be a different crate
FWIW, it can't. Rust enforces that either the trait or the type being impld
come from the current crate (with generics it gets more complicated).
I kinda feel like upgrading HeapSizeOf to have a generic second trait-bound
argument that we substitute MallocSizeO
On Fri, Oct 6, 2017 at 2:33 PM, Xidorn Quan wrote:
>
> There are multiple Servo dependencies on crates.io depend on heapsize.
> [1] How are they handled at the moment? And what would we do to them in
> the future with the second option?
>
> [1] https://crates.io/crates/heapsize/reverse_dependenci
On Fri, Oct 6, 2017, at 12:27 PM, Nicholas Nethercote wrote:
> I see two options.
>
> - Overwrite the heapsize crate on crates.io with the malloc_size_of code.
> So
> the crate name wouldn't change, but the API would change significantly,
> and
> it would still be on crates.io. Then switch Ser
Hi,
Currently we have two similar but distinct approaches to measuring memory
usage
in Servo.
- Servo uses the heapsize and heapsize_derive crates, from crates.io.
- Gecko uses the malloc_size_of and malloc_size_of_derive crates, which are
in
the tree.
Because of this, you see this pattern qu
13 matches
Mail list logo
