Peeking into scavenging work

[Pawel Kozlowski]

Hi there!

It might be more of the dev tools question than V8 question, but let me try it anyway...

So, I'm trying to better understand how scavenger goes about its business, or more precisely, what ends up in the young generation space and gets subsequently collected.

I'm working on a lib where I see non-negligible scavenging pauses (±4ms which is significant for my use-case). After poking here and there I've realized that I don't understand what _exactly_ ends up int the young generation space. Of course I _know_ what objects I'm creating myself but it seems that there is more memory allocated _somewhere_ that makes scavenging work kicking in. 

I'm guess I'm trying to answer the following question: what is there on the young generation space when scavenger kicks in. Is there any way (even the most obscure tooling) to "see" those objects?

If not, I would have 2 "proxy" question:

- what happens (in terms of memory) when creating new DOM objects? Where are those allocated and what ends up on the young generation space (just a pointer? full DOM object?)

- is optimizing compiler generating any objects that end up on the young generation space and can trigger  scavenging work?

Sorry if I'm totally confusing things here, but just starting to explore inner workings of memory allocation / young generation... Any guidance would be more than appreciated.

Cheers,

Pawel

[Michael Lippautz]

On Sat, Jul 22, 2017 at 9:59 AM Pawel Kozlowski <pkozlowski...@gmail.com> wrote:

Hi there!

It might be more of the dev tools question than V8 question, but let me try it anyway...

So, I'm trying to better understand how scavenger goes about its business, or more precisely, what ends up in the young generation space and gets subsequently collected.

For your library you can assume that any objects created by your application will end up in the young generation.

Some internal objects can go directly to the old generation. Additionally, there exist optimizations that allow objects to be allocated directly in the old generation. These are special cases though and in general all objects start in the young generation.

I'm working on a lib where I see non-negligible scavenging pauses (±4ms which is significant for my use-case). After poking here and there I've realized that I don't understand what _exactly_ ends up int the young generation space. Of course I _know_ what objects I'm creating myself but it seems that there is more memory allocated _somewhere_ that makes scavenging work kicking in. 

Maybe another library or dependency? Without JS interaction, v8 doesn't allocate anything in the young generation.

Have you tried recording an allocation profile using DevTools? The idea behind this profile is that dominating allocations (= the ones causing GCs) will show up there.

 

I'm guess I'm trying to answer the following question: what is there on the young generation space when scavenger kicks in. Is there any way (even the most obscure tooling) to "see" those objects?

No, as the heap architecture is an implementation detail and generations don't exist in JS.

 

If not, I would have 2 "proxy" question:

- what happens (in terms of memory) when creating new DOM objects? Where are those allocated and what ends up on the young generation space (just a pointer? full DOM object?)

DOM objects are part of the rendering engine, Blink in V8's case. V8 lazily allocates wrapping objects on the JS heap for those when needed. These end up in the young generation.

 

- is optimizing compiler generating any objects that end up on the young generation space and can trigger  scavenging work?

Code is not allocated in the young generation. The compiler might create a few internal objects but nothing that should cause significant additional scavenging work.

 

Sorry if I'm totally confusing things here, but just starting to explore inner workings of memory allocation / young generation... Any guidance would be more than appreciated.

Cheers,

Pawel

Cheers, Michael