How to track the objects' status in V8?

[Zhao Jiazhong]

Hello everyone,

I found that an online video site may have a really high memory footprint with Chromium90 on LoongArch64 platform, and the JS Heap looks small in devtools.

I have spent some time to debug it, but only found the high memory footprint seems to be caused by many JSArrayBuffers that keep alive for a long time, which are freed soon on other platforms.

And now I have no idea how to find out why those JSArrayBuffers keep alive.

So I wonder how V8 remove the reference to a needless object? And is there a way to dump all the objects' status, like the way from root to a specific object, in V8 or Chromium? Any advice would be appreciated, thanks!

Best regards,

Zhao Jiazhong

[Marja Hölttä]

On Mon, Feb 21, 2022 at 2:48 PM Zhao Jiazhong <zhaojia...@loongson.cn> wrote:

Hello everyone,

I found that an online video site may have a really high memory footprint with Chromium90 on LoongArch64 platform, and the JS Heap looks small in devtools.

I have spent some time to debug it, but only found the high memory footprint seems to be caused by many JSArrayBuffers that keep alive for a long time, which are freed soon on other platforms.

And now I have no idea how to find out why those JSArrayBuffers keep alive.

So I wonder how V8 remove the reference to a needless object?

By using various garbage collection techniques, see e.g., this blog post and video: https://v8.dev/blog/trash-talk 

 

And is there a way to dump all the objects' status, like the way from root to a specific object, in V8 or Chromium? Any advice would be appreciated, thanks!

There is: the "Heap Snapshot" in Dev tools. (Open Dev tools -> Memory -> Take snapshot.) Also this might be helpful: https://developer.chrome.com/docs/devtools/memory-problems/heap-snapshots/

A random guess: function contexts might keep things alive even if they're not really needed. V8's analysis of which variables are really needed by the inner functions (which are currently alive) is quite simple and sometimes overshoots.

- Marja

--

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Zhao Jiazhong]

Hi Marja,

Thanks for your reply! 

I have read the blog, and it says "Garbage collectors do this by using reachability as a proxy for ‘liveness’", but I still don't know when would an object remove the pointer to a needless object, so that the needless object woule be unreachable.

And I also tried the "Heap Snapshot" in Dev tools, but when I start to take the snapshot, those JSArrayBuffer would be freed immediately and the memory footprint drops to a normal level, so there are no those JSArrayBuffers in the snapshot.

Since I can only reproduce this issue on LoongArch64-Linux, other platforms like X64-Linux and MIPS64-Linux are fine, so is the analysis of live range likely to be arch-related? Thanks!

Best regards,

Zhao Jiazhong

[Leszek Swirski]

The heap snapshot forces a garbage collection -- if these objects are freed when you collect the heap snapshot, that means that there are no more live references to them, and the garbage collector simply hasn't run (yet) to collect them. 

If this is happening only on LoongArch64, I can only assume there's some arch-specific difference (code size? pointer compression?) which pushes or doesn't push some heuristic over a threshold where GC does or doesn't happen.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/18d7b43e-af37-49d0-8ad3-00226e66579cn%40googlegroups.com.

[Zhao Jiazhong]

I can see many GCs during the video playing, but those JSArrayBuffers are not freed until the next episode. I have added some logs to GC related functions, it seems those JSArrayBuffers are indeed live. And the number of them could increase to 6000+, leading to 1GB+ memory footprint, which should be around 200MB normally. I'm not sure why the GC made by the heap snapshot could clean them though.

The pointer compression is not implemented on LoongArch64 and MIPS64, but MIPS64 is fine. And I think the code size of LoongArch64 should be between ARM64 and MIPS64.