RFR(S): 8026694: New type profiling points break compilation replay

[Roland Westrelin]

Hi Vladimir,

> I tried to use ReplayCompiles today but got next failure. Will this change fix it? Or I have to file new bug? Or replay file is broken?

If I remember correctly, the change below fixes it:

 575     // To be properly initialized, some profiling in the MDO needs the
 576     // method to be rewritten (number of arguments at a call for
 577     // instance)
 578     method->method_holder()->link_class(CHECK);

src/share/vm/ci/ciReplay.cpp

Roland.

> 
> Thanks,
> Vladimir
> 
> #  Internal Error (src/share/vm/interpreter/bytecode.cpp:123), pid=17421, tid=4151430000
> #  assert(cpcache() != NULL) failed: do not call this from verifier or rewriter
> #
> # JRE version: Java(TM) SE Runtime Environment (9.0-b08) (build 1.9.0-ea-fastdebug-b08)
> # Java VM: Java HotSpot(TM) Server VM (25.0-b62-internal-debug mixed mode linux-x86 )
> 
> V  [libjvm.so+0x4d8081]  report_vm_error(char const*, int, char const*, char const*)+0x70
> V  [libjvm.so+0x2d58a0]  Bytecode_invoke::verify() const+0x80
> V  [libjvm.so+0x3a1a1a]  Bytecode_invoke::Bytecode_invoke(methodHandle, int)+0x60
> V  [libjvm.so+0x8da604]  MethodData::profile_jsr292(methodHandle, int)+0x4e
> V  [libjvm.so+0x8da72e] MethodData::profile_arguments_for_invoke(methodHandle, int)+0x72
> V  [libjvm.so+0x8d844c] MethodData::compute_data_size(BytecodeStream*)+0x208
> V  [libjvm.so+0x8d869d] MethodData::compute_allocation_size_in_bytes(methodHandle)+0x5b
> V  [libjvm.so+0x8d87e6] MethodData::compute_allocation_size_in_words(methodHandle)+0x24
> V  [libjvm.so+0x8d80d6]  MethodData::allocate(ClassLoaderData*, methodHandle, Thread*)+0x26
> V  [libjvm.so+0x405c17]  CompileReplay::process_ciMethodData(Thread*)+0xe3
> V  [libjvm.so+0x405191]  CompileReplay::process_command(Thread*)+0xef
> V  [libjvm.so+0x40501c]  CompileReplay::process(Thread*)+0x56
> V  [libjvm.so+0x40318d]  ciReplay::replay_impl(Thread*)+0xdd
> V  [libjvm.so+0x402e2a]  ciReplay::replay(Thread*)+0x1e
> 
> On 4/23/14 3:44 AM, Roland Westrelin wrote:
>> Thanks for the review, Vladimir.  I need another one. Any taker?
>> 
>> Roland.
>> 
>> 
>> On Apr 18, 2014, at 6:13 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Looks good.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 4/18/14 5:33 AM, Roland Westrelin wrote:
>>>> 
>>>> Here a new webrev with the SA support:
>>>> 
>>>> http://cr.openjdk.java.net/~roland/8026694/webrev.01/
>>>> 
>>>> The ciReplay jtreg tests now pass.
>>>> 
>>>> Roland.
>>>> 
>>>> 
>>>> On Apr 15, 2014, at 11:56 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>> 
>>>>> Roland,
>>>>> 
>>>>> Can you look on compiler/ciReplay/TestSA.sh failure? Is it because of additional metadata?  Will this your change fix it? Do you need to update SA too?
>>>>> 
>>>>> I got next running latest promoted jdk9 fastdebug VM with Tiered off:
>>>>> 
>>>>> WARNING: replay.txt from SA != replay.txt from VM:
>>>>> 
>>>>> < # ciMetadata0 @ sun.jvm.hotspot.oops.TypeArrayKlass at 0x0000000100000030
>>>>> < # Unknown ci type 0xfffffd7ed7ecc5a0
>>>>> ...
>>>>> < # ciMetadata98 @ sun.jvm.hotspot.oops.Method at 0xfffffd7ffccf9da0
>>>>> 504a396,403
>>>>>> ciMethodData java/lang/invoke/MethodHandle <clinit> ()V 1 0 orig 304 104 155 245 215 126 253 255 255 0 0 0 0 0 0 0 0 240 46 198 252 127 253 255 255 208 2 0 0
>>>>> 
>>>>> And:
>>>>> 
>>>>> Exception in thread "main" java.lang.InternalError: missing reason for 17
>>>>>        at sun.jvm.hotspot.oops.MethodData.initialize(MethodData.java:185)
>>>>>        at sun.jvm.hotspot.oops.MethodData.access$000(MethodData.java:36)
>>>>>        at sun.jvm.hotspot.oops.MethodData$1.update(MethodData.java:126)
>>>>>        at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394)
>>>>>        at sun.jvm.hotspot.oops.MethodData.<clinit>(MethodData.java:124)
>>>>> 
>>>>> thanks,
>>>>> Vladimir
>>>>> 
>>>>> On 4/15/14 11:50 AM, Vladimir Kozlov wrote:
>>>>>> On 4/15/14 11:21 AM, Roland Westrelin wrote:
>>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8026694/webrev.00/
>>>>>>>>>>>> 
>>>>>>>>>>>> If we want to still be able to read replay files generated before
>>>>>>>>>>>> this change, the assert:
>>>>>>>>>>>> 
>>>>>>>>>>>> src/share/vm/ci/ciReplay.cpp
>>>>>>>>>>>> 1120       assert(m->_data_size + m->_extra_data_size ==
>>>>>>>>>>>> rec->_data_length * (int)sizeof(rec->_data[0]), "must agree”);
>>>>>>>>>>>> 
>>>>>>>>>>>> needs to removed or changed (extra data from the MDO is not
>>>>>>>>>>>> currently dumped).
>>>>>>>>>> 
>>>>>>>>>> Are you asking what to do with the assert? Can you detect if replay
>>>>>>>>>> file has extra data?
>>>>>>>>> 
>>>>>>>>> I can change the assert to:
>>>>>>>>> 
>>>>>>>>>       assert(m->_data_size + m->_extra_data_size ==
>>>>>>>>> rec->_data_length * (int)sizeof(rec->_data[0]) ||
>>>>>>>>>              m->_data_size == rec->_data_length *
>>>>>>>>> (int)sizeof(rec->_data[0]), "must agree”);
>>>>>>>>> 
>>>>>>>>> and then it covers both cases. There’s no real need to detect
>>>>>>>>> whether the replay file has extra data.
>>>>>>>> 
>>>>>>>> Agree.
>>>>>>> 
>>>>>>> Thanks Vladimir. Can I consider this reviewed?
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> Vladimir
>>>>>> 
>>>>>>> 
>>>>>>> Roland.
>>>>>>> 
>>>> 
>>