RFR: 8276563: Undefined Behaviour in class Assembler [v10]
Thomas Stuefe
stuefe at openjdk.java.net
Fri Nov 19 14:11:45 UTC 2021
On Fri, 19 Nov 2021 14:03:23 GMT, Andrew Haley <aph at openjdk.org> wrote:
>> The HotSpot code base contains a number of instances of Undefined Behavior, which can cause all manner of unpleasant surprises.
>> The UB to which this patch relates is in class `Assembler`, in which instances are pointers to (nonexistent) objects defined as, for example,
>>
>>
>> typedef RegisterImpl *Register;
>> const Register r10 = ((Register)10);
>>
>>
>> Registers have accessors, e.g.:
>>
>> ` int RegisterImpl::encoding() const { return (intptr_t)this; }`
>>
>> This works by an accident of implementation: it is not legal C++.
>>
>> The most obvious way to this UB bug is to make instances of `Register` point to something, and to use pointer subtraction to find the encoding: (simplified for clarity)
>>
>>
>> extern RegisterImpl all_Registers[num_Registers];
>> int RegisterImpl::encoding() const { return this - all_Registers; }
>>
>>
>> After this patch there is slightly more work to be done when assembling code but it's merely the subtraction of a constant in `encoding()` and the difference in execution time is so small (and the startup variance so large) that I have been unable to measure it, even after averaging 100 runs. It does lead to an increase of about 1% in the size of the stripped libjvm.so, but I think that can be recovered by a subsequent patch.
>>
>> An alternative way to implement this would be to make the encoding a byte-wide field in `RegisterImpl` and define encoding() this way:
>>
>> ` int RegisterImpl::encoding() const { return _encoding; }`
>>
>> This would result in smaller code, but I suspect slower.
>>
>> If this change is accepted, I propose that all instances of this pattern in HotSpot be treated similarly.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>
> Delete has_byte_register().
Still good.
-------------
Marked as reviewed by stuefe (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6280
More information about the hotspot-compiler-dev
mailing list