Can a long period of prior load prevent JIT compilation of a method which would otherwise have been compiled?

[Krystal Mok]

Hi,

There's a MemoryPool implementation for CodeHeap, which exposes the usage
of the CodeCache through JMX.
Screenshot of JConsole displaying the usage: [1]

The ObjectName of this MXBean is "java.lang:type=MemoryPool,name=Code
Cache". It can be accessed through
java.lang.management.ManagementFactory.getMemoryPoolMXBeans()

- Kris

[1]:
http://dl.iteye.com/upload/picture/pic/109883/6a832c88-f624-38dc-b43d-b6b4b8fc303c.png

On Thu, Mar 15, 2012 at 1:07 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> Unfortunately we don't have flags in product VM to show CodeCache usage.
> VM should always print next message when CodeCache is full:
>
>
> CodeCache is full. Compiler has been disabled.
> Try increasing the code cache size using -XX:ReservedCodeCacheSize=
>
> Vladimir
>
> Benedict Russell wrote:
>
>> That sounds very plausible, thanks. Is there any way to check code cache
>> usage in an existing process? Does the hotspot compiler always print a
>> warning when the code cache is full or does it sometimes just stop silently?
>>
>> On 12 Mar 2012 16:05, "Azeem Jiva" <azeem.jiva at oracle.com <mailto:
>> azeem.jiva at oracle.com>**> wrote:
>>
>>    It's possible your code cache is full, try:
>>
>>    -XX:ReservedCodeCacheSize=128m
>>
>>
>>    Azeem Jiva
>>    @javawithjiva
>>
>>
>>    On 03/12/2012 10:35 AM, Benedict Russell wrote:
>>
>>>    This mailing list looks like the best bet to get an answer to my
>>> question. However, please let me know if there's somewhere more appropriate
>>> for me to post this question.
>>>
>>>    I'm investigating a performance problem in my application (a
>>> tomcat-based webserver) which has the following characteristics:
>>>
>>>
>>>    - On a server which has just been restarted, uploading a given data
>>> file takes around 5 seconds. I can upload several hundred such files and
>>> the performance remains consistently good.
>>>    - On a server which has been heavily loaded for several days but with
>>> a different load profile (i.e. has handled a very large number of other
>>> requests but NOT any data uploads of this kind), uploading the same data
>>> file takes around 40 seconds.  I've now uploaded nearly 300 such files and
>>> the performance remains consistently bad.
>>>
>>>    - On the slow servers, the CPU is maxed out while handling the
>>> uploads and thread dumps consistently show threads spending lots of time in
>>> runnable state in one particular method - com.sun.mail.util.**
>>> BASE64EncoderStream.write.
>>>
>>>    - jstat output confirms that very little time is being spent in GC in
>>> either case.
>>>
>>>    One possible explanation would be that the com.sun.mail.util.**BASE64EncoderStream.write
>>> method is not being compiled on the servers which have been running for
>>> several days, which might happen if the JIT compiler's view of which
>>> methods should be compiled has become skewed after a few days of different
>>> load. To test whether this could explain the difference, I ran two tests:
>>>
>>>    - Restarted a server with "-XX:+PrintCompilation" and uploaded some
>>> data files. This showed the server compiling the com.sun.mail.util.**BASE64EncoderStream.write
>>> method very early on (as expected), and showing good upload performance
>>> (~5s per file).
>>>    - Restarted the same server with "-XX:CompileCommand=exclude,**
>>> com/sun/mail/util/**BASE64EncoderStream,write" to exclude this method
>>> from compilation. In this case, the performance was very similar to that on
>>> the servers which have handled several days of other load (~40s per file).
>>>
>>>
>>>    So the circumstantial evidence is consistent with the theory, but
>>> that obviously doesn't prove anything.
>>>    A few questions then:
>>>
>>>    1) Is it possible that the JIT compiler is selecting methods for
>>> compilation very differently on the two servers (one freshly restarted and
>>> one after several days of load), or is this fundamentally not how it works?
>>>
>>>    2) Is there any way of checking which methods have been compiled on a
>>> running server? Could I easily prove or disprove the theory without having
>>> to restart all the servers and reproduce this scenario with extra debugging
>>> options?
>>>
>>>    3) If the theory I've suggested isn't plausible, does anyone have any
>>> other ideas what might cause this behaviour?
>>>
>>>    If it makes a difference, the JVM I'm using is
>>>
>>>    java version "1.6.0_07"
>>>
>>>    Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
>>>    Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)
>>>
>>>    Thanks in advance!
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120315/518f24fc/attachment.html