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

[Vladimir Kozlov]

Workaround:

src/share/vm/interpreter/bytecode.hpp
@@ -213,7 +213,7 @@
  // Abstraction for invoke_{virtual, static, interface, special}

  class Bytecode_invoke: public Bytecode_member_ref {
- protected:
+ public:
    // Constructor that skips verification
    Bytecode_invoke(methodHandle method, int bci, bool unused)  : 
Bytecode_member_ref(method, bci) {}

src/share/vm/oops/methodData.cpp
@@ -1419,7 +1419,7 @@
      return true;
    }

-  Bytecode_invoke inv(m , bci);
+  Bytecode_invoke inv(m , bci, false);
    return inv.is_invokedynamic() || inv.is_invokehandle();
  }

Vladimir

On 4/23/14 5:00 PM, Vladimir Kozlov wrote:
> 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.
>>>>>>>
>>>>
>>