Thanks, I've started by setting a breakpoint in v8::internal::V8::FatalProcessOutOfMemory to see how I end up here. Once the process is stopped, I can dig into what's actually going on with the process state.
Thanks for the insight the the TODO message, so the eventual goal (of the TODO) is to attempt to allow some sort of recovery from this state? Is the overall performance of the GC design satisfactory enough that this is probably going to be a back-burner item for a while? Brian On Jun 27, 2012, at 6:32 PM, Vyacheslav Egorov wrote: > You need to catch it in the debugger to see what actually happens. It > can be either: > > - real OOM: OS refused to give memory to V8 (you seem to be confident > that this is not the case) > - heap size limit OOM: ensure that your heap size is not exceeding > --max-old-space-size limit (defaults: 700mb on ia32, 1400mb on x64). > - artificial OOM when trying to allocate an array or a string that is > too big (e.g. check constants SeqAsciiString::kMaxLength, > FixedArray::kMaxLength). > > The cryptic TODO itself comes from V8's early days, short explanation: > some places in V8 runtime (e.g. places that use methods of > v8::internal::Factory) do not expect allocation failures that cannot > be resolved by calling GC (several times in worst case), so > CALL_AND_RETRY can't return Failure object to them (and V8 does not > use exceptions or longjmp in runtime) so it has to fail. TODO reflects > some hope that V8 might start handle OOMs more gracefully in some day > in the future (which is not trivial as OOM might leave VM in > inconsistent state). > > -- > Vyacheslav Egorov > > > On Wed, Jun 27, 2012 at 11:55 PM, Brian Wilson <[email protected]> wrote: >> >> I've been running into some issues lately where I see the message: >> >> FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory >> running a program (it's built on Node.js, but I'm interested in tracing this >> on the v8 level). >> >> From all indications there's plenty of free memory, plenty of heap space and >> the ulimit is not set too low, but we're still seeing this issue. Does >> anyone have any suggestions on how to track down how we're triggering this >> allocation failure? >> >> Incidentally, while browsing through heap-inl.h there's a cryptic TODO... >> fix this. comment. >> >> 540 if (__maybe_object__->IsOutOfMemory() || >> \ >> 541 __maybe_object__->IsRetryAfterGC()) { >> \ >> 542 /* TODO(1181417): Fix this. */ >> \ >> 543 v8::internal::V8::FatalProcessOutOfMemory("CALL_AND_RETRY_2", >> true);\ >> 544 } >> \ >> >> >> Can someone shed light on where that comment came from, what the issue was >> and what fixed it? >> >> >> Thanks, >> Brian -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
