RFR: 8288904: Incorrect memory ordering in UL [v2]

Johan Sjölén duke at openjdk.org
Wed Jun 22 19:54:45 UTC 2022


On Wed, 22 Jun 2022 18:58:37 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Johan Sjölén has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment the loadstore
>
> src/hotspot/share/logging/logOutputList.cpp line 51:
> 
>> 49:   // Prevent mutations to the output list to float above the active reader check.
>> 50:   // Such a reordering would lead to readers loading faulty data.
>> 51:   OrderAccess::loadstore();
> 
> Just got curious about this memory ordering problem. How can a write after the while loop be executed(and be seen by other threads) without even knowing if we can bail out of the while loop. So I'm thinking that otherwise this program would crash:
> 
> 
> volatile int never_touched_variable = 0;
> int* address = (int*)0xBADC0FEE;
> 
> int main() {
> 	while(never_touched_variable == 0) {}
> 	*address = 1;
> 	return 0;
> 
> }

I'm going by ARM's memory model, which is understood by me as something like: "Any nondependent loads and stores may be observed in a different order than program order". Dependency here means register or address dependency.

I think your program is allowed to crash, because I think you're invoking UB by making and dereferencing a pointer to random memory.

-------------

PR: https://git.openjdk.org/jdk/pull/9225


More information about the hotspot-runtime-dev mailing list