[LLVMdev] getElapsedWallTime unnecessary heap allocation and memory leak
Kostya Serebryany
kcc at google.com
Wed Mar 19 07:28:39 PDT 2014
On Wed, Mar 19, 2014 at 6:18 PM, Bryan Keiren <
bryan.keiren at guerrilla-games.com> wrote:
> We are indeed trying to completely clean the heap before exiting main().
>
Which means that you either don't have threads, or you join all threads
before main exits.
Is that the case?
Good for you if so!
>
>
> -----Original Message-----
> From: Caldarale, Charles R [mailto:Chuck.Caldarale at unisys.com]
> Sent: Wednesday, March 19, 2014 14:42
> To: Bryan Keiren; llvmdev at cs.uiuc.edu
> Subject: RE: [LLVMdev] getElapsedWallTime unnecessary heap allocation and
> memory leak
>
> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> > On Behalf Of Bryan Keiren
> > Subject: [LLVMdev] getElapsedWallTime unnecessary heap allocation and
> > memory leak
>
> > In the file \lib\Support\Process.cpp on line 60, it seems as though an
> > unnecessary heap allocation and memory leak occurs.
>
> > static TimeValue getElapsedWallTime() {
> > static TimeValue &StartTime = *new TimeValue(TimeValue::now());
> > return TimeValue::now() - StartTime;
> > }
>
> > The issue is that the StartTime variable's value is allocated on the
> > heap, after which a *reference* to it is stored (not the pointer
> > itself). This means that the allocated memory is actually never properly
> de-allocated.
>
> Since the StartTime field is static, why is this considered a leak? The
> reference has not been lost and is utilized whenever getElapsedWallTime()
> is invoked. Although it might be infinitesimally more efficient to avoid
> the new operator, the overall memory consumption is almost identical.
>
> Are you trying to get rid of the entire heap at some point before process
> termination?
>
> - Chuck
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140319/37c36f16/attachment.html>
More information about the llvm-dev
mailing list