Crash with "assert(number_of_codes <= 256) failed: too many bytecodes"

Karen Kinnear karen.kinnear at oracle.com
Thu Jul 27 17:50:46 UTC 2017


We missed a change in byte codes.cpp:

Need to move the def(_vgetfield down to the JVM byte codes and add the additional field which is _getfield as the java_code.

thanks,
Karen

> On Jul 27, 2017, at 1:34 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi Karen,
> 
> On 27.07.2017 19:30, Karen Kinnear wrote:
>> Do you want to change in ByteCodes.java - 
>> ByteCodeCount to 210 instead of 216?
> 
> Right, that count should be updated as well.
> 
> I just run this through JPRT and I get dozens of failures:
> 
> #  Internal Error (/scratch/opt/jprt/T/P1/170707.tohartma/s/hotspot/src/share/vm/interpreter/bytecodeStream.hpp:210), pid=10773, tid=10777
> #  assert(Bytecodes::is_java_code(code)) failed: sanity check
> 
> Stack: [0x00007fc4238db000,0x00007fc4239db000],  sp=0x00007fc4239d72d0,  free space=1008k
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x16aee0f]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x15f
> V  [libjvm.so+0x16afbbf]  VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
> V  [libjvm.so+0xad92fd]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
> V  [libjvm.so+0xb0e5d8]  BytecodeStream::next()+0x158
> V  [libjvm.so+0xd65088]  RetTable::compute_ret_table(methodHandle const&)+0x48
> V  [libjvm.so+0xd67c7d]  GenerateOopMap::compute_map(Thread*)+0x31d
> V  [libjvm.so+0x1327c7a]  OopMapForCacheEntry::compute_map(Thread*)+0xba
> V  [libjvm.so+0x1329aa6]  OopMapCacheEntry::fill(methodHandle, int)+0x136
> V  [libjvm.so+0x132b2ab]  OopMapCache::lookup(methodHandle const&, int, InterpreterOopMap*) const+0x1bb
> V  [libjvm.so+0x126587a]  Method::mask_for(int, InterpreterOopMap*)+0x5a
> V  [libjvm.so+0xc1e97e]  frame::oops_interpreted_do(OopClosure*, RegisterMap const*, bool)+0xb0e
> V  [libjvm.so+0x15dd2ba]  JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x21a
> V  [libjvm.so+0x15e799e]  Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x4e
> V  [libjvm.so+0xd36be1]  GenCollectedHeap::process_roots(StrongRootsScope*, GenCollectedHeap::ScanningOption, OopClosure*, OopClosure*, CLDClosure*, CLDClosure*, CodeBlobToOopClosure*)+0x81
> V  [libjvm.so+0xd36fdc]  GenCollectedHeap::young_process_roots(StrongRootsScope*, OopsInGenClosure*, OopsInGenClosure*, CLDClosure*)+0x4c
> V  [libjvm.so+0xaf22e4]  DefNewGeneration::collect(bool, bool, unsigned long, bool)+0x554
> V  [libjvm.so+0xd3a576]  GenCollectedHeap::collect_generation(Generation*, bool, unsigned long, bool, bool, bool, bool)+0x356
> V  [libjvm.so+0xd3bb28]  GenCollectedHeap::do_collection(bool, bool, unsigned long, bool, GenCollectedHeap::GenerationType)+0x338
> V  [libjvm.so+0xa02ebd]  GenCollectorPolicy::satisfy_failed_allocation(unsigned long, bool)+0xed
> V  [libjvm.so+0x16b059d]  VM_GenCollectForAllocation::doit()+0xcd
> V  [libjvm.so+0x16ebfc9]  VM_Operation::evaluate()+0xa9
> V  [libjvm.so+0x16e8fbf]  VMThread::evaluate_operation(VM_Operation*)+0x34f
> V  [libjvm.so+0x16e98a9]  VMThread::loop()+0x269
> V  [libjvm.so+0x16e9f50]  VMThread::run()+0xc0
> V  [libjvm.so+0x1347982]  thread_native_entry(Thread*)+0x112
> 
> Maybe it's best to back out 8185349 for now.
> 
> Best regards,
> Tobias
> 
>> Maurizio’s call - this is compiler sources,
>> 
>> thanks,
>> Karen
>> 
>>> On Jul 27, 2017, at 12:18 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>> 
>>> Okay, it's getting complicated. Here are the webrevs:
>>> 
>>> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.36.jdk/
>>> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.36.langtools/
>>> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.36.hs/
>>> 
>>> What do you think?
>>> 
>>> Best regards,
>>> Tobias
>>> 
>>> On 27.07.2017 18:08, Tobias Hartmann wrote:
>>>> 
>>>> On 27.07.2017 17:58, Maurizio Cimadamore wrote:
>>>>> Wait - if you update these opcodes, then we need to update bytecode library as well - see
>>>>> 
>>>>> jdk.experimental.bytecode.Opcode
>>>> 
>>>> Right:
>>>> 
>>>> diff -r 2e4c9a8ae4e3 src/java.base/share/classes/jdk/experimental/bytecode/Opcode.java
>>>> --- a/src/java.base/share/classes/jdk/experimental/bytecode/Opcode.java	Thu Jul 27 15:59:25 2017 +0100
>>>> +++ b/src/java.base/share/classes/jdk/experimental/bytecode/Opcode.java	Thu Jul 27 18:07:52 2017 +0200
>>>> @@ -235,14 +235,11 @@
>>>>    VSTORE(204),
>>>>    VALOAD(205),
>>>>    VASTORE(206),
>>>> -    VNEW(207),
>>>> -    VRETURN(210),
>>>> -    VGETFIELD(211),
>>>> -    TYPED(212),
>>>> -    VDEFAULT(214),
>>>> -    VWITHFIELD(215),
>>>> -    VBOX(216),
>>>> -    VUNBOX(217);
>>>> +    VRETURN(207),
>>>> +    VDEFAULT(208),
>>>> +    VWITHFIELD(209),
>>>> +    VBOX(210),
>>>> +    VUNBOX(211);
>>>> 
>>>>    int code;
>>>> 
>>>> 
>>>> And I guess we have to change this as well:
>>>> 
>>>> diff -r 298730c35452 src/jdk.jdeps/share/classes/com/sun/tools/classfile/Opcode.java
>>>> --- a/src/jdk.jdeps/share/classes/com/sun/tools/classfile/Opcode.java	Thu Jul 27 16:00:29 2017 +0100
>>>> +++ b/src/jdk.jdeps/share/classes/com/sun/tools/classfile/Opcode.java	Thu Jul 27 18:08:20 2017 +0200
>>>> @@ -247,13 +247,13 @@
>>>>    VSTORE(204, LOCAL),
>>>>    VALOAD(205),
>>>>    VASTORE(206),
>>>> -    VRETURN(210),
>>>> +    VRETURN(207),
>>>> 
>>>> -    VDEFAULT(214, CPREF_W),
>>>> -    VWITHFIELD(215, CPREF_W),
>>>> +    VDEFAULT(208, CPREF_W),
>>>> +    VWITHFIELD(209, CPREF_W),
>>>> 
>>>> -    VBOX(216, CPREF_W),
>>>> -    VUNBOX(217, CPREF_W),
>>>> +    VBOX(210, CPREF_W),
>>>> +    VUNBOX(211, CPREF_W),
>>>> 
>>>>    // impdep 0xfe: PicoJava nonpriv
>>>>    // impdep 0xff: Picojava priv
>>>> 
>>>> 
>>>> Thanks,
>>>> Tobias
>>>> 
>>>>> On 27/07/17 16:31, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> seems like this is due to:
>>>>>> http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/dbb31857c4d4
>>>>>> 
>>>>>> If I count correctly, adding _vgetfield at the end 'causes number_of_codes' to be 257 and thus we fail.
>>>>>> 
>>>>>> We should reset the value type bytecode numbers:
>>>>>> 
>>>>>> diff -r 5cd8d5559192 src/share/vm/interpreter/bytecodes.hpp
>>>>>> --- a/src/share/vm/interpreter/bytecodes.hpp    Thu Jul 27 16:00:00 2017 +0100
>>>>>> +++ b/src/share/vm/interpreter/bytecodes.hpp    Thu Jul 27 17:23:40 2017 +0200
>>>>>> @@ -248,11 +248,11 @@
>>>>>>     _vstore               = 204, // 0xcc
>>>>>>     _vaload               = 205, // 0xcd
>>>>>>     _vastore              = 206, // 0xce
>>>>>> -    _vreturn              = 210, // 0xd2
>>>>>> -    _vdefault             = 214, // 0xd6
>>>>>> -    _vwithfield           = 215, // 0xd7
>>>>>> -    _vbox                 = 216, // 0xd6
>>>>>> -    _vunbox               = 217, // 0xd7
>>>>>> +    _vreturn              = 207, // 0xcf
>>>>>> +    _vdefault             = 208, // 0xd0
>>>>>> +    _vwithfield           = 209, // 0xd1
>>>>>> +    _vbox                 = 210, // 0xd2
>>>>>> +    _vunbox               = 211, // 0xd3
>>>>>>       number_of_java_codes,
>>>>>> 
>>>>>> Thanks,
>>>>>> Tobias
>>>>> 
>> 



More information about the valhalla-dev mailing list