Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finding out memory usage in C++ #8082

Closed
pweiskircher opened this issue Feb 13, 2019 · 5 comments
Closed

Finding out memory usage in C++ #8082

pweiskircher opened this issue Feb 13, 2019 · 5 comments
Labels

Comments

@pweiskircher
Copy link
Contributor

We have a pretty big app running using Emscripten that has to handle some pretty big PDF files sometimes. We try to cache as much data as possible, to make runtime performance as good as possible. On iOS and Android, we use the OS memory notifications to reduce memory as needed.

I haven't found a way yet in WASM/asmjs to do something similar. I understand there aren't any memory notifications, but, for example, is there a way to get the size of the heap when ALLOW_MEMORY_GROWTH is defined?

Basically, any information that I can query at runtime to see how much memory is used or available would be extremely beneficial. Our application is unfortunately not designed to behave correctly when malloc fails (due to so many operating systems simply overcommiting anyway), so we're running into OOM situations quite often.

BTW, thanks for all the work on it, it's been working really great so far!

@kripken
Copy link
Member

kripken commented Feb 15, 2019

You can find the current size of the heap from any of the views, HEAP8.length for example.

There is also the --memoryprofiler option which can give more detailed info - may be useful in itself, or just to look at the output it adds to see how it finds the various values (although those are all internal details, and may change).

@Matheus28
Copy link

Matheus28 commented Feb 24, 2019

If you want current memory usage (not just total heap size), (uintptr_t) sbrk(0) also works. It's what I use but I'm not sure how reliable that is.

@ryszardgrzesica
Copy link

I think that --memoryprofiler does not count "DYNAMIC memory area used" properly in case of multithreaded system (just shows main thread allocs). Also sbrk seems to be not useful since show similar thing like "DYNAMIC memory area size" so summarized memory allocated also by other threads than main but never updates whilst free/delete is called. Additionally --memoryprofiler cost some performance. Luckily there is relatively simple workaround (but at the cost of memory overhead with small impact on performance).

Just override new/malloc/free/delete with your own implementation:

  1. Define some shared memory space for book keeping of current memory consumption level and peak memory consumption level (since your memory usage may be ok for 99% of time and you are killed by some peaks when you decode)
  2. Define some header space - where you will keep size of alloced memory, it should have alignment of the biggest alignment unit - in my case it need to be 64bit header. From your overriden new/malloc return pointer to working space - so after the header. Increment your counters at every malloc/new
  3. When free/delete find size to be subtracted from counters and free properly whole space along with size header

@ryszardgrzesica
Copy link

Do not forget to override Module._malloc (if you call such from JS) with ccall to your version of malloc. And at init time (as son as possible) initiate counters with what sbrk returns to have good starting point of measurements.

@stale
Copy link

stale bot commented Apr 16, 2020

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Apr 16, 2020
@stale stale bot closed this as completed Apr 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants