RFR (M): 8184334: Generalizing Atomic with templates

Kim Barrett kim.barrett at oracle.com
Tue Aug 8 02:26:54 UTC 2017

> On Aug 6, 2017, at 7:32 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> I've included a mechanism for dealing with thin wrappers over
> primitive types.  The driver for this is oop, which is normally just a
> typedef for oopDesc*, but is a class with an oopDesc* member when
> CHECK_UNHANDLED_OOPS is defined (such as during fastdebug builds).  We
> (Erik and I) knew we would need something there, if only for the case
> of oop, but hadn't agreed on a solution.  Well, I'm proposing one here.

If this really is only needed for oop with CHECK_UNHANDLED_OOPS, an
alternative to this general IntegerTypes::Translate mechanism (and
making the Atomic/OrderedAccess layer pay attention to it) would be to
make that special oop class definition deal with the problem.  In
oopsHierarchy.hpp, #include atomic.hpp (and eventually
orderAccess.hpp) and add definitions like following after the class
definition for oop (replacing the proposed Translate specialization)

inline oop Atomic::cmpxchg(oop exchange_value,
                           oop volatile* dest,
                           oop compare_value,
                           cmpxchg_memory_order order) {
  return oop(Atomic::cmpxchg(exchange_value.obj(),
                             reinterpret_cast<oopDesc* volatile*>(dest),

and similarly for all the other Atomic and OrderAccess operations that
we want to accept oop arguments.  This is kind of ugly, in that it
puts all these definitions far away from where one might expect to
find them.  But then, this whole "oop is a typedef except when it's a
class" thing is kind of ugly too.  This also runs into include order
problems; I'm not sure how hard those would be to deal with.

Right now I'm inclined to stick with the Translate mechanism,
especially because of the unknowns involved in the include order
problem.  Consider the Translate mechanism to be the usual additional
level of indirection needed to solve a problem.

More information about the hotspot-dev mailing list