Is it safe to take heap snapshots in the NearHeapLimitCallback?

[Joyee Cheung]

I had been thinking that taking heap snapshots should not be viable since this also consumes memory, but it seems to work just fine when I tried to implement it in Node.js https://github.com/nodejs/node/pull/33010 - probably because taking the heap snapshot doesn't really consume that much memory from the V8 heap, it just mostly uses usual native memory ?

And the fact that taking heap snapshots triggers GC seem to help generating multiple snapshots for users to compare, compared to writing just one when V8 is about to crash which is what https://github.com/blueconic/node-oom-heapdump does with the OOM callback. Though thinking about it a bit more, if node-oom-heapdump has been working, then at least taking heap snapshots is already safe even when the heap limit is already reached.

My question is, is this safe? Or to what extent is this safe?

[Ulan Degenbaev]

Hi Joyee,

The heap snapshot indeed uses native memory. The only caveat with taking heap snapshot inside NearHeapLimitCallback is that the callback may be invoked by one of the GCs that are triggered by the heap snapshot generator. So the callback has to be re-entrant (it seems that your PR is already handling this case). If the second callback does not increase the heap limit sufficiently (e.g. max young generation size ~ 32MB by default) then the GC may crash with OOM because it may need to promote young objects into the old generation, which checks the limit.

Other than that it should be safe.

Cheers,

Ulan.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/3bdb87b9-4833-4629-bf98-2ce5a66746cc%40googlegroups.com.

[Joyee Cheung]

Hi Ulan,

Thanks for the explanation!

> If the second callback does not increase the heap limit sufficiently (e.g. max young generation size ~ 32MB by default) then the GC may crash with OOM because it may need to promote young objects into the old generation, which checks the limit.

So IIUC, the safe thing to do should be to return a new limit that's initial_heap_limit + max_young_generation_size in the second callback. From what I can tell, there should two ways to get to the young generation size:

- Save the max_young_generation_size_in_bytes() from the resource constraints used to create the isolate.

- Do a GetHeapSpaceStatistics() in the callback, and filter out the one with the name "new_space", then use the space_size() of that particular item.

Which one would be more preferable? My guess is the first one might be larger than the second one, but probably not by lot, and it saves the filtering code and  thus is more reliable.

Also, is it  safe to assume that the GC triggered by snapshot generation will not invoke the NearHeapLimitCallback more than once? Or should I guard against more potential invocations?

Joyee

To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

[Ulan Degenbaev]

> Which one would be more preferable? 

Either option would work. Please note that there is also a new-large-object space that is also a part of the young generation. Perhaps, a simpler overapproximation would be to double the current heap limit? That is definitely larger than the young generation size.

> Also, is it  safe to assume that the GC triggered by snapshot generation will not invoke the NearHeapLimitCallback more than once? 

I think so. If the limit is increased sufficiently, then the NearHeapLimitCallback more than once by snapshot GCs.

Cheers,

Ulan.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/1b3c41d8-8c40-48b2-9086-ce9695bbbb3c%40googlegroups.com.

[Joyee Cheung]

> Perhaps, a simpler overapproximation would be to double the current heap limit? That is definitely larger than the young generation size.

My finding was that since V8 can only restore the limit when the actual heap usage drops below the new limit, for a program with unbounded heap growth, if the heap usage never drops below that even after GCs, the limit can never be restored, and the program will crash eventually with about 2x of the initial heap limit, effectively doubling the max heap size. Therefore, the smaller the room we leave for this, the less it will affect the final memory usage of the program (or less likely to run into system OOM).

I will try with saving the max young generation size in the resource constraints. Thanks for the insight!

Joyee

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/1b3c41d8-8c40-48b2-9086-ce9695bbbb3c%40googlegroups.com.