Looks fine to me. Please go ahead. 2011/7/8 Wu Yongchong <wuyongch...@gmail.com>: > I update the patch to add more comments. > > In this situation, priority_fn has a member __curbb_list witch is a > std::list, it would not use the memory pool _hb_pool, but cycle_fn has > not member that use memory outside pool _hb_pool > > Index: osprey/be/cg/hb_sched.cxx > =================================================================== > --- osprey/be/cg/hb_sched.cxx (revision 3678) > +++ osprey/be/cg/hb_sched.cxx (working copy) > @@ -2951,6 +2951,9 @@ > #if defined (TARG_SL) > LOCS_Fwd_Scheduling = org_LOCS_Fwd_Scheduling; > #endif > + // cycle_fn will be deleted when _hb_pool is freed, while > priority_fn used malloc pool > + // to initialize its _curbb_list, so we explicitly delete it to > aviod memory leak. > + CXX_DELETE(priority_fn, &_hb_pool); > } > > void > > On Thu, Jul 7, 2011 at 10:12 AM, Jian-Xin Lai <laij...@gmail.com> wrote: >> Another object cycle_fn is allocated in the same way as priority_fn >> and it's not freed, too. Could you please also check the cycle_fn? >> >> 2011/7/4 Wu Yongchong <wuyongch...@gmail.com>: >>> Can a gate keeper help review this patch >>> >>> Class Priority_Selector(declared in open64/osprey/be/cg/hb_sched.h) >>> has a member std::list<BB*> _curbb_list . Although we use local memory >>> pool when we call the constructor, the _curbb_list still use new >>> operator to allocate memory. So that this memory block is leaked even >>> if the local memory pool is freed. This patch will call the destructor >>> explicitly. >>> >>> Index: osprey/be/cg/hb_sched.cxx >>> =================================================================== >>> --- osprey/be/cg/hb_sched.cxx (revision 3669) >>> +++ osprey/be/cg/hb_sched.cxx (working copy) >>> @@ -2951,6 +2951,7 @@ >>> #if defined (TARG_SL) >>> LOCS_Fwd_Scheduling = org_LOCS_Fwd_Scheduling; >>> #endif >>> + CXX_DELETE(priority_fn, &_hb_pool); >>> } >>> >>> void >>> >>> -- >>> yongchong >>> >>> ------------------------------------------------------------------------------ >>> All of the data generated in your IT infrastructure is seriously valuable. >>> Why? It contains a definitive record of application performance, security >>> threats, fraudulent activity, and more. Splunk takes this data and makes >>> sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-d2d-c2 >>> _______________________________________________ >>> Open64-devel mailing list >>> Open64-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>> >> >> >> >> -- >> Regards, >> Lai Jian-Xin >> > > > > -- > yongchong >
-- Regards, Lai Jian-Xin ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
