Re: [dev-servo] Memory reporting in Servo: the next step

​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

Re: [dev-servo] Memory reporting in Servo: the next step

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

Re: [dev-servo] Memory reporting in Servo: the next step

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

Re: [dev-servo] Memory reporting in Servo: the next step

> 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

Re: [dev-servo] Memory reporting in Servo: the next step

> 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

Re: [dev-servo] Memory reporting in Servo: the next step

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

Re: [dev-servo] Memory reporting in Servo: the next step

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

Re: [dev-servo] Memory reporting in Servo: the next step

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

Re: [dev-servo] Memory reporting in Servo: the next step

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'

Re: [dev-servo] Memory reporting in Servo: the next step

> 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

Re: [dev-servo] Memory reporting in Servo: the next step

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]

Re: [dev-servo] Memory reporting in Servo: the next step

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

[dev-servo] Memory reporting in Servo: the next step

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