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

[Erik Österlund]

On Wed, 22 Jun 2022 19:51:34 GMT, Johan Sjölén <duke at openjdk.org> wrote:

>> 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.

I suppose the memory state change due to calling free on a node can reorder to before the load checking there are no readers. The. The memory can appear to be free memory and get allocated to random other memory that changes state arbitrarily, while there is still a concurrent reader.

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

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