erik.osterlund at lnu.se
Mon Jan 12 13:18:21 UTC 2015
Thank you for clearing things out, it really helps talking to the person
who originally wrote this code!
It seems to me that this code was written at a time when it was vaguely
and incorrectly documented both what the hardware and compilers
guarantee. Must have been a nightmare! I think it's still vague today.
On 09/01/15 23:45, Paul Hohensee wrote
> We understood that volatile semantics wouldn't be enough by themselves
> to implement the semantics we wanted ordering on most platforms, but
> they *are* necessary to prevent compilers (not the hardware though) from
> reordering volatile accesses with respect to each other. Whether or not
> the volatile keyword prevents non-volatile memory accesses from being
> reordered wrt volatile ones seemed a bit fuzzy in the C++ standard at
> the time (and still does, at least to me), but we figured we could
> handle that in the os_cpu files by checking which compiler was being
> used. The code that implemented the *hardware* semantics also went into
> the os_cpu file(s). That's why there's some seemingly silly code there,
> including assembly that executes what amount to nops.
I agree it was and still is very vague which is why different compilers
interpreted it differently. MSVC is explicit about using acquire release
for volatiles (wanted) and GCC is explicit about not guaranteeing
non-volatile w.r.t. volatile. I have not read anything explicit from the
others so will assume it's unsafe to rely on anything unless we find
explicit proof it is reliable.
I saw the strange barriers with nops and dummy volatile writes you speak
of, and intend to change these to normal compiler barriers instead.
Because the dummy volatile memory accesses don't actually give us the
guarantees we want for the same reason outlined before (volatile
semantics not good enough), while also looking a bit strange at the same
> I initially wrote the code in factored form, but changed to the current
> scheme because I found it difficult to see all the code for a single
> platform in one place (I wasn't using an IDE :) ). In retrospect, an
> unwise decision due to the usual code duplication problems. Mea culpa. :)
Thank you for the background and useful context Paul!
More information about the hotspot-dev