RFR (M): 8188813: Generalize OrderAccess to use templates
david.holmes at oracle.com
Fri Oct 6 06:01:46 UTC 2017
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 the
ptr variants at some stage.
Can you declare "volatile jbyte* byte = ..." to avoid the volatile cast
on the orderAccess call?
> Testing: mach5 hs-tier3
> Since Atomic already has a mechanism for type checking generic arguments
> for Atomic::load/store, and OrderAccess also is a bunch of semantically
> decorated loads and stores, I decided to reuse the template wheel that
> was already invented (Atomic::LoadImpl and Atomic::StoreImpl).
> Therefore, I made OrderAccess privately inherit Atomic so that this
> infrastructure could be reused. A whole bunch of code has been nuked
> with this generalization.
> It is worth noting that I have added PrimitiveConversion functionality
> for doubles and floats which translates to using the union trick for
> casting double to and from int64_t and float to and from int32_t when
> passing down doubles and ints to the API. I need the former two, because
> Java supports volatile double and volatile float, and therefore runtime
> support for that needs to be able to use floats and doubles. I also
I didn't quite follow that. What parts of the runtime need to operate on
volatile float/double Java fields?
> 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