> 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. On Thu, Apr 23, 2020 at 2:56 PM Joyee Cheung <jo...@igalia.com> wrote: > 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 > > On Thursday, April 23, 2020 at 3:01:42 PM UTC+8, Ulan Degenbaev wrote: >> >> 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. >> >> On Thu, Apr 23, 2020 at 1:50 AM Joyee Cheung <jo...@igalia.com> wrote: >> >>> 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? >>> >>> -- >>> -- >>> 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-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 >>> <https://groups.google.com/d/msgid/v8-users/3bdb87b9-4833-4629-bf98-2ce5a66746cc%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > -- > v8-users mailing list > v8-users@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+unsubscr...@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 > <https://groups.google.com/d/msgid/v8-users/1b3c41d8-8c40-48b2-9086-ce9695bbbb3c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- v8-users mailing list v8-users@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CABNJt2%2B_63NP%3DWeHCpznBisNT0URWzSfhsZB-N6CQHVnPiGGsA%40mail.gmail.com.
