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

[Vladimir Kozlov]

Roland,

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?

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