Hi, I have found only one instantiation of the List<T,P> template with T=Code* and P=FreeStoreAllocationPolicy it type alias --- CodeList (see list.h).
The only instance of the CodeList I could find is allocated on the stack (see KeyedIC::ComputeStub) and should not leak. But this interpretation does not fit your trace. So I think we can assume that compiler merged some template methods together and it's either List<Handle<Object> > entered_contexts_; or List<Context*> saved_contexts_; that get resized when you perform Context::Enter. My guess would be that you have unbalanced Context::Enter and Context::Exit so your stacks of entered/saved contexts grow without bounds. Please check that they are balanced. You can also add some debug prints into Context::Enter to see length of entered_contexts_ stack. -- Vyacheslav Egorov On Fri, Sep 2, 2011 at 4:09 PM, Stuart <[email protected]> wrote: > The system is still running and has since allocated 2 x 150MB more > using > v8::internal::List<v8::internal::Code*,v8::internal::FreeStoreAllocationPolicy>::Resize > > The stack profile is similar; calling back into V8 using stored > function and parameter handles. > > Any clues? Am I even correct in assuming this has been allocated for > code and not data? > > Stuart. > > >> *,v8::internal::FreeStoreAllocationPolicy>::Resize > > On Aug 31, 10:46 pm, Stuart <[email protected]> wrote: >> I need some help understanding this call stack. >> >> The resize results in a 47MB allocation that never gets freed. This >> happened twice during a 6 hour run. >> >> StackTrace Content >> v8director!v8::internal::List<v8::internal::Code >> *,v8::internal::FreeStoreAllocationPolicy>::Resize+22 bytes, 0xE6BF76 >> v8director!v8::Context::Enter+199 bytes, 0xE1F2D7 >> v8director!`anonymous namespace'::DecoupledCall::call >> v8director! >> boost::asio::detail::completion_handler<boost::_bi::bind_t<void,boost::_mfi >> ::mf0<void,`anonymous >> >> DecoupledCall is making a synchronous (no locks) call into V8 using >> previously stored persistent handles to a function and parameters. I >> have seen this leak occur twice with this stack, but is exceptionally >> rare; two times over thousands and thousands of iterations. I would >> love to learn that it is related to this stack, but I suspect it's a >> coincidence. >> >> The parameter v8::internal::Code suggests this is an allocation for >> code. Why would V8 suddenly need 50MB of code storage after running >> the same thing for 6 hours? >> >> What am I seeing? Could a closure cause this? Would any logging help? >> >> Stuart. > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
