RFR: 8189871: Refactor GC barriers to use declarative semantics

[Erik Österlund]

Hi Kim,


On 2017-11-21 19:48, Kim Barrett wrote:
>> On Nov 21, 2017, at 11:20 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> I am merely more precisely annotating that unsafe accesses on oops have explicitly unknown oop ref strength. However, the GC backends do not do more about it than they did before. I.e. only G1 loads check the actual reference strength and act accordingly (as before), and other exotic accesses are treated the same in the backends (as before) since their pre-write barriers are enough anyway. The behaviour is the same before and after.
> For the operations in question, there were no checks for reference
> strength before, not even for G1. So the behavior is not the same
> before and after the Access changes.
>
> Unsafe_CompareAndExchangeObject on a referent was effectively UB. I
> don't think adding the special handling for referents makes it any
> less UB; it's still an abuse of Unsafe to break invariants. In which
> case, any potential additional work that might be done to handle that
> specific case is not just pointless, but actively harmful.

For the operations in question, there were no checks for reference 
strength before or after. The unsafe.cpp file annotates that this is an 
unknown oop ref, the backends don't check for it or care. Seems very 
much the same to me. Am I missing something?

Thanks,
/Erik

>> Thanks,
>> /Erik
>>
>> On 2017-11-21 08:07, Kim Barrett wrote:
>>> Noticed another issue while looking for something else.
>>>
>>> Before these changes, Unsafe_CompareAndExchangeObject does not
>>> specially handle Reference referents. Attempting to do so is new
>>> behavior introduced by Access. I don't think that change should be
>>> made. I think anyone who uses an Unsafe compare and swap to modify the
>>> referent of a reference deserves all the pain and suffering we can
>>> inflict upon them. With Unsafe, just because the current
>>> implementation doesn't outright prevent something doesn't make it a
>>> valid thing to do. There are many ways to (mis)use Unsafe that create
>>> havoc by breaking invariants and such. Consider the damange that could
>>> be done by using Unsafe to modify the discovered field of a reference,
>>> for example.
>>>
>>> I haven't looked for other similar "quiet changes".
>>>
>>> I'm also finding what look to me like some inconsistencies between the
>>> documentation for Unsafe and the implementation, but except for things
>>> like the above they are pre-existing.
>