[LLVMdev] GSoC'09 question - previous mail w/o html

[Mihai Balint]

On Mar 29, 2009, at 2:56 AM, Bill Wendling wrote:
> On Mar 28, 2009, at 1:34 AM, Mihai Balint wrote:
>> On Mar 28, 2009, at 4:39 AM, Anthony Danalis wrote:
>>> On Mar 27, 2009, at 9:15 PM, Dan Gohman wrote:
>>>>
>>>> On Mar 26, 2009, at 8:28 AM, Mihai Balint wrote:
>>>>> This summer however, I plan to create an "optimization" that
>>>>> automatically fixes memory leaks in programs - obviously only  
>>>>> those
>>>>> that can be fixed with the available information, for example:
>>>>
>>>> Hello,
>>>>
>>>> This doesn't sound advisable.  A memory leak in a normal C/C++
>>>> program
>>>> is a bug, so this wouldn't be an optimization -- it'd be a
>>>> transformation that
>>>> unreliably hides bugs.
>>>>
>>> It doesn't sound correct either.  I, for one, have a multithreaded
>>> code where all "created" threads allocate "request" objects, put  
>>> them
>>> in a list and wake up the main thread.  The main thread on the other
>>> hand sleeps, consumes requests, frees the objects it consumed and
>>> goes
>>> back to sleep in a loop.  There is no path between the malloc() and
>>> the free(), but that's how it is supposed to be, there is no leak.
>>>
>>
>> You are right it's not an optimization, it is a bug-fixing
>> transformation and I wasn't really planning on being totally silent
>> and covert about anything I find (fixable or not).
>>
> This sounds more like something that could be added to the clang
> static analyzer ( http://clang.llvm.org/StaticAnalysis.html ).

I just skimmed through clang's static analyzer web-pages and couldn't  
find an example analysis, I will dig deeper later. One of the reasons  
why llvm is preferred is because of the SSA form representation which  
makes analysis implementation easier - but then again I haven't seen a  
clang static analysis yet...

> I'm not
> a big fan of the compiler changing the semantics of code that a
> programmer wrote. It's full of pitfalls. If, on the other hand, you
> can tell the programmer that there's the potential for a leak and let
> her determine if it's a "real" leak, that would be much better for all
> concerned.

As it turns out there have been some experiments with a static,  
compile-time garbage collector for Java, ( http://www.cs.cornell.edu/projects/frex/index.php 
  ) and in one of the papers they say they were able to statically  
deallocate 50%-85% of objects - but for Java where GC is assumed and  
there's no address-of operator.

best wishes.

Mihai.