[9] RFR: 8044538: assert(which != imm_operand) failed: instruction is not a movq reg, imm64
Christian Thalinger
christian.thalinger at oracle.com
Tue Jun 10 15:38:16 UTC 2014
Looks good.
On Jun 10, 2014, at 8:04 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> Hi Chris,
>
>> Your @run command uses the wrong class name:
>>
>> 28 * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp -XX:+PrintRelocations Test8044538
>> 35 public class TestPrintRelocations {
>
> Thanks, I missed that while renaming. Should have tested it..
>
> New webrev: http://cr.openjdk.java.net/~thartmann/8044538/webrev.04/
>
> Best,
> Tobias
>
>>
>> On Jun 9, 2014, at 11:10 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>>>> 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.
>>>>>> We are trying to not use bug id directories anymore. Please move the test to a more meaningful directory with a meaningful name.
>>>>> Okay, makes sense. I moved the test to test/compiler/PrintRelocations/TestPrintRelocations.java
>>>> Thanks but that’s too fine grained. I doubt there will be any other PrintRelocations tests. So maybe test/compiler/relocations/ makes more sense.
>>>
>>> Okay, I moved it to test/compiler/relocations.
>>>
>>> New webrev: http://cr.openjdk.java.net/~thartmann/8044538/webrev.03/
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>
>>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8044538/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>>>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140610/1989b722/attachment.html>
More information about the hotspot-compiler-dev
mailing list