llvm dev - Mar 2011 - [LLVMdev] Prevent unbounded memory consuption of long lived JIT processes

On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen
wrote:
> On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote:
> 
> > This series of patches address several issues causing memory usage to
grow
> > indefinetely on a long lived process.
> 
> Thanks for working on this.
> 
> Did you measure the performance impact of these changes?
I tracked performance with this change with X86 JIT and there was no
measurable difference, but the performance was governed more by the
quality of the compiled code, and not so much the compilation time.

If you can point me to a good compilation time benchmark I can get some
figures.

I'd expect either no measurable impact in compilation time, or a slight
improvement due to smaller memory footprint:

- for patches 1-3 (prevent infinite growth of several hash maps data
types) should above all reduce memory usage; there might be some cases
(e.g., frequent updates with a small bounded number of elements) where
it may trade off an exponentially growing table size (i.e., memory) for
more rehashes (i.e., cpu), but that should be a win on nowadays
processors.

- patch 4 (Reset StringMap's NumTombstones on clears and rehashes)
should improve performance

- patch 5 refers to a function that doesn't get called frequently

Jose

On Mar 16, 2011, at 6:19 AM, José Fonseca wrote:
> On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote:
>> On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote:
>> 
>>> This series of patches address several issues causing memory usage
to grow
>>> indefinetely on a long lived process.
>> 
>> Thanks for working on this.
>> 
>> Did you measure the performance impact of these changes?
> 
> I tracked performance with this change with X86 JIT and there was no
> measurable difference, but the performance was governed more by the
> quality of the compiled code, and not so much the compilation time.
> 
> If you can point me to a good compilation time benchmark I can get some
> figures.
I normally use 403.gcc, but if you don't have SPEC sources, these tests in
the nightly test suite take a while to compile:

MultiSource/Applications/ClamAV
MultiSource/Applications/JM/ldecod
MultiSource/Applications/JM/lencod
MultiSource/Applications/SPASS
MultiSource/Applications/kimwitu++/kc
MultiSource/Applications/sqlite3/sqlite3

If you run 'make TEST=nightly', both llc and opt compile times are
interesting. The runtime of opt is cryptically reported in the GCCAS column.

/jakob

On 03/16/2011 03:39 PM, Jakob Stoklund Olesen wrote:
> On Mar 16, 2011, at 6:19 AM, José Fonseca wrote:
>
>    
>> On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote:
>>      
>>> On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote:
>>>
>>>        
>>>> This series of patches address several issues causing memory
usage to grow
>>>> indefinetely on a long lived process.
>>>>          
>>> Thanks for working on this.
>>>
>>> Did you measure the performance impact of these changes?
>>>        
>> I tracked performance with this change with X86 JIT and there was no
>> measurable difference, but the performance was governed more by the
>> quality of the compiled code, and not so much the compilation time.
>>
>> If you can point me to a good compilation time benchmark I can get some
>> figures.
>>      
> I normally use 403.gcc, but if you don't have SPEC sources, these tests
in the nightly test suite take a while to compile:
>
> MultiSource/Applications/ClamAV
> MultiSource/Applications/JM/ldecod
> MultiSource/Applications/JM/lencod
> MultiSource/Applications/SPASS
> MultiSource/Applications/kimwitu++/kc
> MultiSource/Applications/sqlite3/sqlite3
>
> If you run 'make TEST=nightly', both llc and opt compile times are
interesting. The runtime of opt is cryptically reported in the GCCAS column.
>
> /jakob
>
>    
Jakob,

Thanks for the detailed instructions.

I've finally got around to build and run the nightly tests, with and 
without my changes, and times on the GCCAS column vary a few percent on 
both directions. That is, whatever effect my change has is lost in noise.

I'm going to re-submit my patches to llvm-commits.

Jose