meaning of usedJsHeapSize and totalJsHeapsize?

1,958 views
Skip to first unread message

gu...@weisscher.nl

unread,
Mar 26, 2012, 7:05:51 AM3/26/12
to google-chrome-...@googlegroups.com
hi all,

I have been looking into these options for some time now and still could not figure out the exact difference between the two.
I would expect usedJsHeapSize to be the actual amount of memory being used, and totalJsHeapsize the max heapsize being used until that moment.
I have done lots of testing with these values but the totalJsHeapsize is almost always lower than the usedJsHeapsize, so exactly the other way around.

any help would be appreciated.

guus

Yury Semikhatsky

unread,
Mar 26, 2012, 7:56:19 AM3/26/12
to gu...@weisscher.nl, google-chrome-...@googlegroups.com
On Mon, Mar 26, 2012 at 3:05 PM, <gu...@weisscher.nl> wrote:
hi all,

I have been looking into these options for some time now and still could not figure out the exact difference between the two.
I would expect usedJsHeapSize to be the actual amount of memory being used, and totalJsHeapsize the max heapsize being used until that moment.
usedJsHeapSize is the total amount of memory being used by JS objects including V8 internal objects, totalJsHeapSize is current size of the JS heap including free space not occupied by any JS objects. This means that usedJsHeapSize can not be greater than totalJsHeapSize. Note that it is not necessarily that there has ever been totalJsHeapSize of alive JS objects.

 
I have done lots of testing with these values but the totalJsHeapsize is almost always lower than the usedJsHeapsize, so exactly the other way around.

That's weird. Could you file a bug on this at http://crbug.com/new and provide some details on how we could reproduce this?
 
Yury

gu...@weisscher.nl

unread,
Mar 26, 2012, 8:54:30 AM3/26/12
to google-chrome-...@googlegroups.com, gu...@weisscher.nl
Well, filing a bug would not be the problem. Providing details on how you could reproduce this will;
In fact, we have not been developing javascript but EGL. (IBM's generation language). Frontend EGL applications generate js. Since we have been struggling with memory-issues for some time now we encapsulated some really simple js-functions to retrieve js-heap information programmatically.
And this info is really helpfull, we're just having a little trouble in interepreting the numbers the produce.
We do not have the skills to provide you with detailed info on how to re-produce these issues in js directly.

Do you happen to know if there is any more info to find on these dev-tool arguments. (I already found the chrome devtools docs, but they only mention the existence of these functions and give no background information.

With kind regards,
Guus


Op maandag 26 maart 2012 13:56:19 UTC+2 schreef Yury Semikhatsky het volgende:

Mikhail Naganov

unread,
Mar 26, 2012, 10:08:31 AM3/26/12
to gu...@weisscher.nl, google-chrome-...@googlegroups.com
Hi Guus,

What version of V8 do you have (available via chrome://version/)?
There was a bug http://code.google.com/p/v8/issues/detail?id=1893.

gu...@weisscher.nl

unread,
Mar 26, 2012, 10:54:04 AM3/26/12
to google-chrome-...@googlegroups.com, gu...@weisscher.nl, mnag...@chromium.org
Hi Mikhail,
We are running on Chrome 15, V8 3.5.10.22.
The issue you mentioned is from V8 3.7 or higher. So I guess this is not the case.
By the way, upgrading to Chrome 17 is an option neither, since the --enable-memory-info switch does not seem to work in it. (read this in multiple forum-topics).


Op maandag 26 maart 2012 16:08:31 UTC+2 schreef Mikhail Naganov het volgende:

Mikhail Naganov

unread,
Mar 27, 2012, 5:26:37 AM3/27/12
to gu...@weisscher.nl, google-chrome-...@googlegroups.com
Right. You should wait for Chrome 18, which is currently in beta.
Reply all
Reply to author
Forward
0 new messages