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

[Tobias Hartmann]

Hi Vladimir,

thanks for the review.

> Looks good. PrintRelocations flag is used very rare, that is why it 
> rotted. Please, add jreg test (use -XX:+IgnoreUnrecognizedVMOptions). 

I added a jtreg test to test/compiler/8044538/ that uses -Xcomp and 
-XX:+PrintRecolations. It fails without my changes.

New webrev: http://cr.openjdk.java.net/~thartmann/8044538/webrev.01/

> Since this debug flag almost never used backporting the fix only into 
> 8u may be enough.

Okay.

Thanks,
Tobias

>
> Thanks,
> Vladimir
>
> On 6/4/14 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
>>
>>