[9] RFR(S): 8064892: Non-methods code cache overflow is not handled correctly

[Vladimir Kozlov]

The print code (include guarding check) should be under #ifdef ASSERT since the flag is debug flag.
Otherwise looks good. So JFR will get this new message instead. Right?

Thanks,
Vladimir

On 8/17/16 4:04 AM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8064892
> http://cr.openjdk.java.net/~thartmann/8064892/webrev.00/
>
> There are two problems with the current handling of code cache exhaustion:
> 1) If the non-nmethod code heap is full, we always try to use the non-profiled or the profiled code heap as a fallback. If those heaps are full as well, we issue a warning stating that the last tried code heap is full. Like this, we never print a warning for the non-nmethod code heap.
> 2) If a code heap is full but we still have enough space in another code heap, no warning or JFR event is triggered.
>
> I fixed 1) by keeping track of the originally requested code blob type and use it for printing the code cache full message if allocation in other heaps failed. Regarding 2), I don't think a code cache full message or JFR event should be triggered because the code cache is not full, we just failed to allocate in the preferred segment. In general, this is expected because the amount of code generated at runtime is not static but segment sizes are. The user should not worry about such fallbacks and therefore we should only print a warning if the entire code cache is full. However, to keep track of this, I added debug output that can be enabled via -XX:+PrintCodeCacheExtension and prints a message if allocation in the preferred segment failed. For example, "Extension of CodeHeap 'non-nmethods' failed. Trying to allocate in CodeHeap 'non-profiled nmethods'".
>
> Tested with JPRT and RBT (running).
>
> Thanks,
> Tobias
>