RFR: 8241438: Move IntelJccErratum mitigation code to platform-specific code
Erik Österlund
erik.osterlund at oracle.com
Thu Apr 2 09:36:57 UTC 2020
Hi Vladimir,
Thanks for the review.
/Erik
On 2020-04-02 04:57, Vladimir Kozlov wrote:
> On 4/1/20 3:24 AM, Erik Österlund wrote:
>> Hi Vladimir,
>>
>> On 2020-03-30 21:14, Vladimir Kozlov wrote:
>>> But you at least can do static check at the beginning of method:
>>>
>>> int MachNode::pd_alignment_required() const {
>>> if (VM_Version::has_intel_jcc_erratum()) {
>>> PhaseOutput* output = Compile::current()->output();
>>> Block* block = output->block();
>>> int index = output->index();
>>> assert(output->mach() == this, "incorrect iterator state in
>>> PhaseOutput");
>>> if (IntelJccErratum::is_jcc_erratum_branch(block, this, index)) {
>>> // Conservatively add worst case padding. We assume that
>>> relocInfo::addr_unit() is 1 on x86.
>>> return IntelJccErratum::largest_jcc_size() + 1;
>>> }
>>> }
>>> return 1;
>>> }
>>
>> That is equivalent to the compiler. I verified that by disassembling
>> the release bits before
>> and after your suggestion, and it is instruction by instruction the
>> same. In both cases it
>> first checks ifVM_Version::has_intel_jcc_erratum(), and if not,
>> returns before even building
>> a frame. I'd rather keep the not nested variant because it is
>> equivalent, yet easier to read.
>
> I have reservation about this statement which may not true for all C++
> compilers we use but I will not insist on refactoring it.
>
>>
>>>>
>>>>> In compute_padding() reads done under check so I have less
>>>>> concerns about it. But I also don't get why you use saved _mach
>>>>> instead of using MachNode 'this'.
>>>>
>>>> Good point. I changed to this + an assert checking that they are
>>>> indeed the same.
>>>
>>> Why do you need Output._mach at all if you use it only in this
>>> assert? Even logically it looks strange. In what case it could be
>>> different?
>>
>> It should never be different; that was the point. The index and mach
>> node exposed by the
>> iterator are related and refer to the same entity. So if you use the
>> exposed index in code
>> in a mach node, you must know that this mach node is the same mach
>> node that the index refers
>> to, and it is. The assert was meant to enforce it so that if you were
>> to call either the
>> alignment or padding function in a new context, for whatever reason,
>> and don't happen to know
>> that you can't do that without having a consistent iteration state,
>> you would immediately catch
>> that in the assertions, instead of getting strange silent logic errors.
>>
>> Having said that, I am okay with removing _mach if you prefer having
>> one seat belt less, it is up to you:
>> http://cr.openjdk.java.net/~eosterlund/8241438/webrev.03/
>
> Okay. Good.
>
> Thanks,
> Vladimir
>
>>
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8241438/webrev.02_03/
>>
>> Thanks,
>> /Erik
>>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> Here is an updated webrev with your concerns and Vladimir Ivanov's
>>>> concerns addressed:
>>>> http://cr.openjdk.java.net/~eosterlund/8241438/webrev.02/
>>>>
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~eosterlund/8241438/webrev.01_02/
>>>>
>>>> Thanks,
>>>> /Erik
>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>>>
>>>>>>> In pd_alignment_required() you implicitly use knowledge that
>>>>>>> relocInfo::addr_unit() on x86 is 1.
>>>>>>> At least add comment about that.
>>>>>>
>>>>>> I can add a comment about that.
>>>>>>
>>>>>> New webrev:
>>>>>> http://cr.openjdk.java.net/~eosterlund/8241438/webrev.01/
>>>>>>
>>>>>> Incremental:
>>>>>> http://cr.openjdk.java.net/~eosterlund/8241438/webrev.00_01/
>>>>>>
>>>>>> Thanks,
>>>>>> /Erik
>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 3/23/20 6:09 AM, Erik Österlund wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> There is some platform-specific code in PhaseOutput that deals
>>>>>>>> with the IntelJccErratum mitigation,
>>>>>>>> which is ifdef:ed in shared code. It should move to
>>>>>>>> platform-specific code.
>>>>>>>>
>>>>>>>> This patch exposes the iteration state of PhaseOutput, which
>>>>>>>> allows hiding the Intel-specific code
>>>>>>>> completely in x86-specific files.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8241438/webrev.00/
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8241438
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> /Erik
>>>>>>
>>>>
>>
More information about the hotspot-compiler-dev
mailing list