RFR (XS) 8006851: When TieredCompilation is set, max code cache should be bumped to 256mb

[Kirk Pepperdine]

Hi Charlie,

+1 on the organically growing request. I wrote a little visualvm plugin called Memory Pool View for the purpose of being able to chart code cache occupancy. The plugin is now part of the download center.

Other things I've done, turn off decay. When I've done this I've benched with -Xcomp to try to get an estimate of how big the code cache might grow. Not perfect but....

Regards,
Kirk
On 2013-02-08, at 10:10 PM, Charlie Hunt <chunt at salesforce.com> wrote:

> Fyi, it's not just FMW apps that require a (much) larger than the default code cache size. ;-)
> 
> Also realize that it's not generally obvious or trivial for a user, or administrator of a Java to know when or if their app is experiencing an out of code cache situation.  Yeah, there's a message emitted when code cache is full, but realize not everyone sees it.  And, how may that do know what to do about it.
> 
> Btw, +1 on the idea of having code cache grow organically.
> 
> hths,
> 
> charlie ...
> 
> On Feb 6, 2013, at 1:57 PM, Azeem Jiva wrote:
> 
>> After thinking about this, maybe setting initial code cache isn't all 
>> that necessary?  Really only FMW apps need that much code cache and not 
>> necessarily initially. We should let the code cache grow organically.  
>> Also you'll need a check to make sure that the user didn't set the code 
>> cache already, otherwise you are overriding their preferences :)
>> 
>> 
>> 
>> On 2/6/2013 11:43 AM, Morris Meyer wrote:
>>> Folks,
>>> 
>>> I'd like to get this small change reviewed.  Per the workflow this has 
>>> gone through JPRT.
>>> 
>>> Thanks in advance,
>>> 
>>>       --morris
>>> 
>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-8006851
>>> WEBREV - http://cr.openjdk.java.net/~morris/8006851
>> 
>