RFR: 8327647: Occasional SIGSEGV in markWord::displaced_mark_helper() for SPECjvm2008 sunflow [v4]
Dean Long
dlong at openjdk.org
Fri Apr 26 19:33:50 UTC 2024
On Fri, 26 Apr 2024 17:50:03 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:
>>> And on the reading side, we'll need two load fences. If that total order is more than is necessary, OK.
>>
>> On the read side, I don't think we read _get_code or _put_code for the fast bytecode path, so that's why there is only one barrier needed.
>
> If I understand correctly, it seems like we agree on where the membar belongs, is this right @dean-long? The current placement of the LoadLoad barrier inside `load_field_entry` seems to be sufficient, and to reiterate information from the description, tier 1-5 test results look clean.
@matias9927, yes that's right. But I agree with earlier reviewer comments that the comment above the LoadLoad could be improved. To me it's helpful to think of this as a kind of self-modifying code. We had a slow bytecode that used the operands in a certain way. Then we changed the opcode to a fast bytecode that uses the operands to access newly initialized data outside the bytecode stream. The LoadLoad makes sure we don't read any of the newly initialized data before we read that the bytecode has been changed to the fast version.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18477#issuecomment-2080006453
More information about the hotspot-compiler-dev
mailing list