[jboss-jira] [JBoss JIRA] (AS7-4547) The JVM option -XX:+TieredCompilation is being set for HotSpot JVM's in standalone.sh, but this slows throughput in all tested workloads

[Thomas Whitmore (JIRA)]

    [ https://issues.jboss.org/browse/AS7-4547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099654#comment-13099654 ] 

Thomas Whitmore edited comment on AS7-4547 at 8/18/15 10:35 PM:
----------------------------------------------------------------

Could the performance loss actually be due to JVM CodeCache exhaustion? Default Java CodeCache size is quite low (48M/96M) and the JIT compiler switches off *permanently* once usage nears the ceiling.

We have a large system & needed to up our CodeCache to 256m minimum (now running with 400m as our default recommendation). Our symptoms were subtle & initially misattributed, this is a tricky issue.

-XX:ReservedCodeCacheSize=400m

Tiered compilation should not cause performance loss, but can contribute to the above exhaustion & subsequent performance loss. 

See a few references:  
- http://blogs.atlassian.com/2012/05/codecache-is-full-compiler-has-been-disabled/
--  (don't follow their tip to turn on CodeCache Flushing, there are actually major bugs there that can, on their own, cause severe degraded JVM performance.)
- https://blog.codecentric.de/en/2012/07/useful-jvm-flags-part-4-heap-tuning/
- https://www-304.ibm.com/connections/blogs/wcs/entry/performance_roadblock_full_jit_cache?lang=en_us

Hope this helps.


was (Author: thomasw08):
Could the performance loss actually be due to JVM CodeCache exhaustion? Default Java CodeCache size is quite low (48M/96M) and the JIT compiler switches off *permanently* once usage nears the ceiling.

We have a large system & needed to up our CodeCache to 256m minimum (now running with 400m as our default recommendation). Our symptoms were subtle & initially misattributed, this is a tricky issue.

-XX:ReservedCodeCacheSize=400m

Tiered compilation should not cause performance loss, but can contribute to the above exhaustion & subsequent performance loss. 

See also a few references:  
- http://blogs.atlassian.com/2012/05/codecache-is-full-compiler-has-been-disabled/
--  (don't follow their tip to turn on CodeCache Flushing, there are actually major bugs there that can, on their own, cause severe degraded JVM performance.)
- https://blog.codecentric.de/en/2012/07/useful-jvm-flags-part-4-heap-tuning/
- https://www-304.ibm.com/connections/blogs/wcs/entry/performance_roadblock_full_jit_cache?lang=en_us

Hope this helps.

> The JVM option -XX:+TieredCompilation is being set for HotSpot JVM's in standalone.sh, but this slows throughput in all tested workloads
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-4547
>                 URL: https://issues.jboss.org/browse/AS7-4547
>             Project: Application Server 7
>          Issue Type: Enhancement
>    Affects Versions: 7.1.1.Final
>            Reporter: Andrig Miller
>            Assignee: Andrig Miller
>             Fix For: 7.1.2.Final (EAP)
>
>
> The standalone.sh script is detected the HotSpot JVM (Oracle JVM or OpenJDK JVM), and setting -XX:+TieredCompilation.  This setting slows throughput on performance workloads such as our internal EJB 3 application, SPECjbb2005, and SPECjEnterprise2010, by some 3 to 5%.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)