[9] RFR: 8044538: assert(which != imm_operand) failed: instruction is not a movq reg, imm64

[Tobias Hartmann]

>> Hi Dean,
>>
>>> 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/
>
> You can also get rid of:
>      address target = _target;
>      if (target == NULL) {
> in internal_word_Relocation::fix_relocation_after_move.

But then we always execute new_addr_for(..). Isn't this a problem?

Thanks,
Tobias


>
>>
>> Thanks,
>> Tobias
>>
>>>
>>> dl
>>>
>>> On 6/4/2014 1:30 AM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch for bug 8044538.
>>>>
>>>> *Problem*
>>>> 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 
>>>> internal_word_Relocation::target(). 
>>>> 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
>>>>
>>>> *Solution*
>>>> 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 
>>>> internal_word_Relocation::fix_relocation_after_move(..).
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8044538/webrev.00/
>>>>
>>>> *Tests*
>>>> 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?
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140605/06ee582d/attachment.html>