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

[Vladimir Kozlov]

On 4/24/14 12:12 AM, Roland Westrelin wrote:
> 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);

Yes, it fixed the problem I see.
When you are going to push these changes?
Can I take only this small point fix into my changes for 8039298?
I'm modifying ciReplay to not abort when it can't load dynamic class.

Thanks,
Vladimir

>
> 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.
>>>>>>>>
>>>>>
>>>
>