Ran
|
Jobs
1
|
Files
73
|
Run time
6s
|
Badge
Embed ▾
README BADGES
|
push
github-actions
Stronger memory-order for when setting a value The plain write to the value piggybacked on the volatile fence when the lock is released for guaranteed visibility. However, we should not assume that visibility delayed until this fence, as the underlying system may inject a fence earlier (e.g. safepont, context switch). As the compiler may change program order for plain reads and writes, those cases must ensure that there is are no dependencies for partial visibility. While true for strong values, the change in 37c51d5c2 shows a dependency order is needed for weak/soft values. For stricter correctness, clearing the Reference must occur after the entry's value has been visibly changed. Therefore, the release/acquire ordering is used to ensure we abide by the Java Memory Model, rather than on x86's total store order (TSO). For more details, see http://gee.cs.oswego.edu/dl/html/j9mm.html
6206 of 6708 relevant lines covered (92.52%)
0.93 hits per line
ID | Job ID | Ran | Files | Coverage | |
---|---|---|---|---|---|
1 | #2606.1 | 73 |
92.52 |
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line |
---|