Code cache

[Eric Caspole]

Yes, if your live working set size of compiled methods is bigger or  
very close to the code cache size then  +UseCodeCacheFlushing won't  
really help, because it will keep trying to recompile the methods and  
throw them away over and over.


On Apr 20, 2012, at 12:24 PM, Alex Aisinzon wrote:

> Eric
>
> I tried -XX:+UseCodeCacheFlushing and associated performance/ 
> scalability was markedly poorer than increasing the code cache.
> I will stick to tuning the code cache.
>
> Best
>
> Alex A
>
> -----Original Message-----
> From: Alex Aisinzon
> Sent: Thursday, April 12, 2012 1:31 PM
> To: 'Eric Caspole'
> Cc: hotspot-gc-use at openjdk.java.net
> Subject: RE: Code cache
>
> Hi Eric
>
> I thank you for the feedback. I will give this tuning a try.
> I have explored another approach: I have added the option -XX: 
> +PrintCompilation to track code compilation.
> This option is not very documented. I could infer that, without a  
> larger code cache, about 11000 methods were compiled before hitting  
> the issue.
> When using a much larger cache (512MB), I saw that about 14000  
> methods were compiled.
> My understanding is that the code cache is 48MB for the platform I  
> used (x64). A 14000/11000*48MB aka 61MB cache is likely to avoid  
> the issue. I have started a performance test with a 64MB code cache  
> to see if that indeed avoids the code cache full issue.
>
> If so, I would have a method to find the right code cache size.
> I will report when I have the results. I will also report if -XX: 
> +UseCodeCacheFlushing option provides similar results to the larger  
> code cache.
>
> As for your question on why our app is hitting this issue: our  
> applications has become heavier in its use of compiled code so this  
> is likely the consequence of that.
>
> Best
>
> Alex A
>
> -----Original Message-----
> From: Eric Caspole [mailto:eric.caspole at amd.com]
> Sent: Thursday, April 12, 2012 12:26 PM
> To: Alex Aisinzon
> Cc: hotspot-gc-use at openjdk.java.net
> Subject: Re: Code cache
>
> Hi Alex,
> You can try -XX:+UseCodeCacheFlushing where the JVM will selectively
> age out some compiled code and free up code cache space. This is not
> on by default in JDK 6 as far as I know.
>
> What is your application doing such that it frequently hits this
> problem?
>
> Regards,
> Eric
>
>
> On Apr 12, 2012, at 3:15 PM, Alex Aisinzon wrote:
>
>> Any feedback on this?
>>
>>
>>
>> Best
>>
>>
>>
>> Alex A
>>
>>
>>
>> From: Alex Aisinzon
>> Sent: Monday, April 09, 2012 11:38 AM
>> To: 'hotspot-gc-use at openjdk.java.net'
>> Subject: Code cache
>>
>>
>>
>> I ran performance tests on one of our apps and saw the following
>> error message in the GC logs:
>>
>> Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full.
>> Compiler has been disabled.
>>
>> Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code
>> cache size using -XX:ReservedCodeCacheSize=
>>
>>
>>
>> I scaled up the code cache to 512MB (-
>> XX:ReservedCodeCacheSize=512m) and markedly improved performance/
>> scalability.
>>
>>
>>
>> I have a few questions:
>>
>> *         Is there a logging option that shows how much of the code
>> cache is really used so that I find the right cache size without
>> oversizing it?
>>
>> *         What factors play into the code cache utilization? I
>> would guess that the amount of code to compile is the dominant
>> factor. Are there other factors like load: I would guess that some
>> entries in the cache may get invalidated if not used much and load
>> could be a factor in this.
>>
>>
>>
>> I was running on Sun JVM 1.6 update 30 64 bit on x86-64.
>>
>>
>>
>> Best
>>
>>
>>
>> Alex A
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>