RFR (S): 8007988: PrintInlining output is inconsistent with incremental inlining

Roland Westrelin roland.westrelin at oracle.com
Tue Mar 18 18:38:21 UTC 2014

The PrintInlining output with incremental inlining can be a mess. Currently it can print 2 lines for a single call site with conflicting messages and when that doesn’t happen sometimes report a failed inlining with a wrong reason.

PrintInlining messages are currently stored in a list of buffers. Every new message is appended to the current buffer in the list. When a call site is enqueued for late inlining then we allocate a new buffer for the subsequent messages and enqueue it after the current buffer. The new buffer becomes the current buffer. When we inline the call site, we can then insert a new buffer for new messages in between the two 2 buffers and keep inlining messages ordered. This doesn’t work well because, when we enqueue a late inlining call site, we’ve already appended the PrintInlining messages for this call site to the current buffer. When we try to inline that late inlining call site, we want to be able to change those messages (it may have failed the first time around but succeeds now or it may have reported success but have been delayed and now we are out of nodes so we can’t do the inlining). To achieve this, this change appends PrintInlining messages for the current call site to a staging buffer, then if the call site is a late inlining call site, we allocate a new buffer and add the messages to that buffer. This way we can go back later and update the messages.

This should also solve the assert failures with PrintInlining that are sometimes seen: https://bugs.openjdk.java.net/browse/JDK-8028274



More information about the hotspot-compiler-dev mailing list