It looks like the profiler counter currently starts at zero [1] whenever the profiler is started. I think it would be more useful to know the actual amount of allocated memory, even if the profiler is started later.

nsMemoryReporterManager::GetHeapAllocated gets the amount of current allocated memory as follows:

  jemalloc_stats_t stats;
  jemalloc_stats(&stats);
  *aAmount = stats.allocated;

[1] In fact, I think the change from bug 1705318 made it so that we usually start out with a negative number: The counter itself starts with zero and then we subtract the memory taken up by profiler buffers.

(In reply to Markus Stange [:mstange] from comment #0)

I think it would be more useful to know the actual amount of allocated memory

That sounds like a good idea with a fairly simple implementation.
Did you have some specific needs, where this information could have been useful to you? (Since you did open this bug!)
In the absolute it feels less valuable, unless we can also record the computer's total memory, and ideally the memory used by the rest of the system.
But I guess it could be nice to compare between Firefox processes. And maybe to catch processes running wild and nomming gigabytes? Though in that case we'd presumably see the memory grow wildly during profiling.

We'll have to make sure the front-end displays it correctly: It displays a relative value based on the start of profiling anyway, so we may need to update it to show the real value.
We may still want the graph to show the relative amount anyway, otherwise it may look very flat if we start with a large value and then only change by a small percentage during profiling.

And one small worry about using nsMemoryReporterManager::GetHeapAllocated is that there could be a small window until the memory interception routines are installed, during which some operations could be missed, so we may not have the exactly-correct value; but it would probably be close, and good enough, in most cases.

(In reply to Gerald Squelart [:gerald] (he/him) from comment #1)

Did you have some specific needs, where this information could have been useful to you? (Since you did open this bug!)

Unfortunately I don't remember why I wanted to see the total memory of a process. I can comment again the next time I run into this.

But it does seem like something that would be generally useful.

We need this. It's not important to have numbers that are exact, it's important to understand the state of each process when the profiler starts.