Brilliant deduction! It was a missing context exit, I'll start another test to run over the weekend. I'm very optimistic.
Thank you very very much. Stuart. On Sep 2, 9:07 pm, Stuart <[email protected]> wrote: > Thank you, I'll take a look. > > Stuart. > > On Sep 2, 10:29 am, Vyacheslav Egorov <[email protected]> wrote: > > > > > 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::FreeStoreAllocationPol > > > icy>::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
