(S) RFR: 8157904: Atomic::cmpxchg for jbyte is missing a fence on initial failure

David Holmes david.holmes at oracle.com
Tue Aug 23 08:55:04 UTC 2016

Hi Volker, Andrew,

On 23/08/2016 12:27 AM, Volker Simonis wrote:
> Hi,
> I don't particularly like the const_casts as well.

I would have thought this was exactly the kind of thing const_cast was 
good for - avoiding the need to define multiple overloads to deal with 
volatile, non-volatile, const etc.

> Why not change pointer_delta to accept pointers to volatiles as well:
> pointer_delta(const volatile void* left, const volatile void* right,

I can do that. I also have to make a similar change to align_ptr_down. 
Now should I also change align_ptr_up for consistency (though I note 
they are already inconsistent in that one takes void* and one takes 
const void*) ?

Alternative webrev at:



> Notice that "const volatile void*" means a pointer to a value which
> might change unexpectedly but which can not be changed by the program
> itself. As the function doesn't really dereferences the pointers (i.e.
> reads the values pointed to by the pointers) but only computes the
> delta of the pointers themselves, this shouldn't do any harm regarding
> the optimization possibilities.
> Because there are standard conversion from "<type>*" to "volatile
> <type>*", the new version will still work for callers which use
> non-volatile arguments.
> Regards,
> Volker
> On Mon, Aug 22, 2016 at 12:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 22/08/2016 6:25 PM, Andrew Haley wrote:
>>> On 22/08/16 08:54, David Holmes wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157904
>>>> webrev: http://cr.openjdk.java.net/~dholmes/8157904/webrev/
>>> The casting away volatile is confusing and ugly.  Is the problem
>>> that we don't have volatile cmpxchg() ?  Or that we don't have a
>>> pointer_delta() which accepts a volatile?
>> The latter - pointer_delta takes const args.
>> David
>>> Andrew.

More information about the hotspot-runtime-dev mailing list