[cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params

[Ted Kremenek]

Applied!

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011422.html

On Jan 27, 2009, at 5:20 PM, Alexei Svitkine wrote:

> Ah, thanks for the clarification.
>
> Here's an updated patch that passes the correct parameters to the
> ASTContext() constructor under each case. I didn't rename the
> parameter in ASTContext however - since it actually does not call
> Deallocate when FreeMemory is false.
>
> -Alexei
>
> On Tue, Jan 27, 2009 at 6:59 PM, Ted Kremenek <kremenek at apple.com>  
> wrote:
>> On Jan 27, 2009, at 3:51 PM, Alexei Svitkine wrote:
>>
>> Oops - it looks like there was a change to ParseAST() earlier that I
>> wasn't up to date with. This one:
>>
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011412.html
>>
>> That change involves propagating the FreeMemory param to the
>> ASTContext constructor... which is problematic with my change which
>> gets rid of that param entirely. I'm not sure how to handle this.
>>
>> The "FreeMemory" argument to ASTContext is a little of a misnomer.   
>> It's
>> more a selector of which Allocator that ASTContext uses to allocate  
>> ASTs
>> (i.e., MallocAllocator or BumpPtrAllocator).  Calling ~ASTContext()  
>> will
>> *always* release memory.  Feel free to rename that parameter to  
>> something
>> more appropriate.
>> Much of your patch is orthogonal to these changes.  Your patch is  
>> about
>> creating a new interface for ParseAST that allows clients to hold  
>> on the
>> TranslationUnit/ASTContext after ParseAST has completed.
>>
>> What is the purpose of -disable-free in the context of the
>> command-line clang tool?
>>
>> Our timings show that a significant amount of time is spent in  
>> clang freeing
>> ASTs.
>> When invoking 'clang' for compilation from the command-line,  
>> freeing ASTs is
>> a waste of time since the OS will automatically reclaim that memory.
>> Providing -disable-free from the command line allows us to  
>> experiment with
>> the performance of just having the OS free memory versus freeing  
>> the memory
>> directly.
>> Moreover, having it as a command-line option (rather than hard- 
>> coded) allows
>> us to free memory ASTs manually for debugging (to make sure all the
>> ownership issues are correct) but still have the --disable-free  
>> option for
>> production releases.
> <ParseAST6.diff>