RFR: 8327647: Occasional SIGSEGV in markWord::displaced_mark_helper() for SPECjvm2008 sunflow [v4]

[Andrew Haley]

On Tue, 23 Apr 2024 02:55:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> If I understand correctly, the order of writes must be:
>>> 
>>>     1. ResolvedFieldEntry fields, except _get_code and _put_code
>> 
>> So, release fence here?
>> 
>>>     2. _get_code, _put_code
>> 
>> and another here
>> 
>>>     3. patch_bytecode(fast_bytecode)
>>> 
>>> 
>>> so the order of reads must be reversed. That's why there are load-acquires when reading _get_code and _put_code. After [3] is done, after dispatching to fast_bytecode, we need to do a LoadLoad between the already read fast bytecode [3] and the "cache" fields [1]. The LoadLoad is not for the load of the next bytecode that will be done in dispatch_next().
>> 
>> So, I guess the loadload fence being inserted here is the one we need between [2] and [3].
>
>> So, I guess the loadload fence being inserted here is the one we need between [2] and [3].
> 
> The way I would say it is we need a LoadLoad betwen [3] and [2] or between [3] and [1].  The code assumes that if it is a fast bytecode, then it can read [1] without checking [2] again.

My confusion is because @dean-long said

_If I understand correctly, the order of writes must be:

    ResolvedFieldEntry fields, except _get_code and _put_code
    _get_code, _put_code
    patch_bytecode(fast_bytecode)_

therefore, if that ordering must be maintained, we'll need two store fences. And on the reading side, we'll need two load fences. If that total order is more than is necessary, OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/18477#issuecomment-2072723032