I believe that is the wasm Memory object itself (Firefox calls it "non-heap" because it isn't a normal item in the Firefox heap, it's not allocated by malloc).
So it looks like your app is requesting more and more memory, and growing the wasm memory steadily. If the --memoryprofiler option doesn't give clear enough info, you can go deeper and manually instrument malloc/free itself, or places that call malloc/free from your code. Another option is to use mallinfo() [1] in various places in your code (before each big chunk of work, for example), to get an idea of where these allocations happen. [1] http://man7.org/linux/man-pages/man3/mallinfo.3.html On Thu, Dec 21, 2017 at 1:04 AM, Zheng Tao Lee <[email protected]> wrote: > Hi Alon, > > i attached the memory report from firefox. seems like most of it ends up > inside non-heap/elements/wasm. > do you have any idea what goes on in allocating memory inside there, or > which tools can i use to measure it? > > Thanks, > Tao > > 1,930.67 MB (100.0%) -- explicit > ├──1,770.97 MB (91.73%) -- workers/workers(localhost) > │ ├──1,718.91 MB (89.03%) -- worker(node_modules/worker.js, 0x1b2cd0d1000) > │ │ ├──1,697.31 MB (87.91%) -- zone(0x1b2d3cd3000) > │ │ │ ├──1,675.74 MB (86.80%) -- compartment(web-worker) > │ │ │ │ ├──1,667.31 MB (86.36%) -- classes > │ │ │ │ │ ├──1,367.89 MB (70.85%) -- class(ArrayBuffer)/objects > │ │ │ │ │ │ ├──1,292.00 MB (66.92%) ── non-heap/elements/wasm > │ │ │ │ │ │ ├─────75.89 MB (03.93%) ── malloc-heap/elements/normal > │ │ │ │ │ │ └──────0.01 MB (00.00%) ── gc-heap > │ │ │ │ │ ├────243.95 MB (12.64%) -- class(WebAssembly.Module)/ > objects > │ │ │ │ │ │ ├──124.56 MB (06.45%) ── non-heap/code/wasm > │ │ │ │ │ │ ├──119.39 MB (06.18%) ── malloc-heap/misc > │ │ │ │ │ │ └────0.00 MB (00.00%) ── gc-heap > │ │ │ │ │ ├─────50.00 MB (02.59%) -- class(SharedArrayBuffer)/objects > │ │ │ │ │ │ ├──50.00 MB (02.59%) ── non-heap/elements/shared > │ │ │ │ │ │ └───0.00 MB (00.00%) ── gc-heap > │ │ │ │ │ └──────5.47 MB (00.28%) ++ (7 tiny) > │ │ │ │ └──────8.43 MB (00.44%) ++ (8 tiny) > │ │ │ └─────21.56 MB (01.12%) ++ (15 tiny) > │ │ └─────21.61 MB (01.12%) ++ (3 tiny) > > > On Thursday, December 21, 2017 at 2:29:00 PM UTC+8, Zheng Tao Lee wrote: >> >> yes the behavior is the same on firefox as well. is there something >> similar for chrome? something like about:memory >> >> Thanks, >> Tao >> >> >> On Wednesday, December 20, 2017 at 12:28:26 PM UTC+8, Alon Zakai wrote: >>> >>> Is the behavior the same on other browsers? It's possible you're running >>> into a Chrome bug here. >>> >>> On Firefox, you can use about:memory to inspect browser memory >>> internally, which might help if the issue is not the wasm memory itself. >>> >>> >>> >>> On Tue, Dec 19, 2017 at 6:38 PM, Zheng Tao Lee <[email protected]> >>> wrote: >>> >>>> any thoughts on how i can find out whats allocating in that private >>>> data? >>>> i used --memoryprofiler and --tracing, but couldnt find anything wrong >>>> with my code. theres lots of memory unaccounted for. >>>> >>>> Thanks, >>>> Tao >>>> >>>> >>>> On Tuesday, December 19, 2017 at 5:56:28 PM UTC+8, Zheng Tao Lee wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am working an a project where we have a model with quite a few lines >>>>> and points, these are allocated in my c++ code. using ALLOW_MEMORY_GROWTH, >>>>> we can see that the memory keeps on growing until it eventually goes out >>>>> of >>>>> memory. >>>>> >>>>> on other platforms the same code runs and uses about 300mb of memory. >>>>> on WASM however it keeps on allocating more. >>>>> >>>>> What i am concerned about is the amount of private data in the working >>>>> set. >>>>> >>>>> Can anyone shine some light on what goes on inside there? i am using >>>>> the sysinternals tool VMMAP to obtain this chart. >>>>> >>>>> >>>>> >>>>> <https://lh3.googleusercontent.com/-WwTr_O2YdzA/WjjgTpFCviI/AAAAAAAABDM/aqN8ASF2dksXcrUSJ91uc7uVeHVoWOUuACLcBGAs/s1600/vmmap_memory%2Bmap.png> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
