RFR: 8044538: assert(which != imm_operand) failed: instruction is not a movq reg, imm64
tobias.hartmann at oracle.com
Thu Jun 5 08:34:38 UTC 2014
> Would it make sense to refactor fix_relocation_after_move() to call
> target() now?
Yes, good point. I refactored it.
New webrev: http://cr.openjdk.java.net/~thartmann/8044538/webrev.01/
> On 6/4/2014 1:30 AM, Tobias Hartmann wrote:
>> please review the following patch for bug 8044538.
>> Executing a debug build of HotSpot with the flags
>> -XX:+PrintRelocations -Xcomp hits a ShouldNotReachHere() or an assert
>> in Assembler::locate_operand(..) stating that the instruction for
>> which we try to find the operand is not valid.
>> The problem occurs while printing the relocation entries for a C2
>> compiled function. The C2 compiler adds internal_word_type
>> relocations for the jump table entries in the constant section of a
>> method (see Compile::ConstantTable::fill_jump_table(...)). These
>> relocations are processed by RelocIterator::print_current(...) and
>> Relocation::pd_get_address_from_code() then tries to retrieve the
>> address from an instruction but fails because the relocation points
>> into the constant section only containing the target address.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044538
>> The implementation of internal_word_Relocation::target() is changed
>> to check if the relocation points into the constant section and if so
>> directly returns the target address instead of trying to retrieve it
>> from an instruction. The same is already done in
>> Webrev: http://cr.openjdk.java.net/~thartmann/8044538/webrev.00/
>> Failing configuration, JPRT
>> Apparently this did not show up for any of our tests. Do we need an
>> additional test for this?
>> Since it already fails for JDK 7 and 8. Should we backport the patch?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev