JDK-8028468 : Add inlining information into ciReplay
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-11-15
  • Updated: 2021-10-27
  • Resolved: 2014-01-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u20Fixed 9 b02Fixed
Related Reports
Relates :  
Relates :  
Description
Add inlining information into ciReplay data to correctly inline methods during recompilation.
Add ability to use ciReplay to compile method DURING normal execution of program.
Currently program is not executed when we do recompilation. 
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/183bd5c00828 User: lana Date: 2014-01-28 05:28:43 +0000
28-01-2014

URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/183bd5c00828 User: kvn Date: 2014-01-08 19:38:57 +0000
08-01-2014

While trying out your patch I found (with your help!) that the code doesn't correctly handle bimorphic inlining, for example: Let's say we have a method which does this, and where there are two implementations of the bar() method: @ 4 java.util.LinkedHashMap::<init> (10 bytes) inline (hot) inline_id=0 @ 1 java.util.HashMap::<init> (11 bytes) inline (hot) inline_id=1 @ 1 java.util.AbstractMap::<init> (15 bytes) inline (hot) inline_id=2 @ 1 java.lang.Object::<init> (1 bytes) inline (hot) inline_id=3 @ 12 java.util.HashMap::<init> (11 bytes) inline (hot) inline_id=0 @ 1 java.util.AbstractMap::<init> (15 bytes) inline (hot) inline_id=5 @ 1 java.lang.Object::<init> (1 bytes) inline (hot) inline_id=6 @ 30 Foo$4::bar (6 bytes) inline (hot) inline_id=0 @ 30 Foo$3::bar (6 bytes) inline (hot) inline_id=0 \-> TypeProfile (457/915 counts) = Foo$3 \-> TypeProfile (458/915 counts) = Foo$4 The inline tree will look like this: 1 java.util.LinkedHashMap::<init> 2 java.util.HashMap::<init> 3 java.util.AbstractMap::<init> 4 java.lang.Object::<init> 5 java.util.HashMap::<init> 6 java.util.AbstractMap::<init> 7 java.lang.Object::<init> 8 Foo$4::bar 14 Foo$4::bar 15 java.lang.Class::getDeclaredFields 16 java.util.Arrays::sort 17 java.util.Arrays$LegacyMergeSort::access$000 9 Foo$3::bar 10 Foo$3::bar 11 java.lang.Class::getDeclaredMethods 12 java.util.Arrays::sort 13 java.util.Arrays$LegacyMergeSort::access$000 Note that the depth first order is not maintained in this case - the second version of bar is processed first. The replay code the assumes the inline order is depth first and you'll run into the assert in InlineTree::dump_replay_data: assert(inline_id() == record, ...);
20-11-2013

Here is initial patch: http://cr.openjdk.java.net/~kvn/replay_inline/webrev/
15-11-2013