RFR (M): 8188813: Generalize OrderAccess to use templates
david.holmes at oracle.com
Fri Oct 6 08:19:47 UTC 2017
On 6/10/2017 4:48 PM, Erik Österlund wrote:
> Hi David,
> On fre, 2017-10-06 at 16:01 +1000, David Holmes wrote:
>> Hi Erik,
>> On 5/10/2017 11:55 PM, Erik Österlund wrote:
>>> Now that Atomic has been generalized with templates, the same
>>> should to
>>> be done to OrderAccess.
>> Well I didn't see anything too scary looking. :) I assume we'll drop
>> ptr variants at some stage.
> Yes, that is indeed the plan.
>> One query:
>> Can you declare "volatile jbyte* byte = ..." to avoid the volatile
>> on the orderAccess call?
> Sure. Fixed.
>>> Testing: mach5 hs-tier3
>>> Since Atomic already has a mechanism for type checking generic
>>> for Atomic::load/store, and OrderAccess also is a bunch of
>>> decorated loads and stores, I decided to reuse the template wheel
>>> was already invented (Atomic::LoadImpl and Atomic::StoreImpl).
>>> Therefore, I made OrderAccess privately inherit Atomic so that
>>> infrastructure could be reused. A whole bunch of code has been
>>> with this generalization.
>>> It is worth noting that I have added PrimitiveConversion
>>> for doubles and floats which translates to using the union trick
>>> casting double to and from int64_t and float to and from int32_t
>>> passing down doubles and ints to the API. I need the former two,
>>> Java supports volatile double and volatile float, and therefore
>>> support for that needs to be able to use floats and doubles. I
>> I didn't quite follow that. What parts of the runtime need to operate
>> volatile float/double Java fields?
> At the moment, there are multiple places that support the use of Java-
> volatile float/double.
> Some examples:
> * The static interpreter supports Java-volatile getfield/putfield (cf.
> cppInterpreter_zero.cpp:588, bytecodeInterpreter.cpp:2023)
Yes this is the _implementation_ of volatile field access for
floats/doubles. I don't count that as a "use". :)
> * unsafe supports getters and setters of Java-volatile doubles/floats
> (cf. unsafe.cpp:476).
Yes this is more of a "use" but again very specific.
> This support is not accidental. The Java language allows the use of
> volatile floats and doubles. Therefore we must support them in our
Not quite what I meant. :) Other than the implementation of the Java
volatile field accesses (direct of via Unsafe or intrinsics) I was
wondering where we might need to do this. The general runtime tends not
to do arbitary orderAccess or atomic operations on floats/doubles.
> Thanks for the review.
>>> added PrimitiveConversion functionality for the subclasses of oop
>>> (instanceOop and friends). The base class oop already supported
>>> this, so
>>> it seemed natural that the subclasses should support it too.
More information about the hotspot-dev