-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8290324: Move atomic operations outside of os_xxx.hpp #9501
8290324: Move atomic operations outside of os_xxx.hpp #9501
Conversation
👋 Welcome back iklam! A progress list of the required criteria for merging this PR into |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems okay - good cleanup.
I'm okay with it if Aarch64 folk are.
Thanks.
@iklam This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
It seems weird that for x86 we have I think all of the 64bit implementations of Maybe these could all be dealt with as followups. Several of the |
For this PR, I just wanted to move code around but otherwise avoid making any actual changes. I'd prefer to do the further clean up in a follow up issue.
That was unintentional. They just happened to be moved to immediate above the only function that uses them, and that function happens to have C linkage. Maybe I should explicitly mark these atomic_copy64 as |
@@ -582,18 +582,23 @@ extern "C" { | |||
*(to--) = *(from--); | |||
} | |||
} | |||
|
|||
inline void atomic_copy64(const volatile void *src, volatile void *dst) { | |||
*(jlong *) dst = *(const jlong *) src; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/jlong/uint64_t/ (or int64_t). And casting away volatile seems kind of sketchy. This could be
Atomic::store((uint64_t*)dst, Atomic::load((const uint64_t*)src));
which seems clearer to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also from the original version. I think we can fix this in a separate PR.
template<> | ||
template<typename T> | ||
inline T Atomic::PlatformLoad<8>::operator()(T const volatile* src) const { | ||
STATIC_ASSERT(8 == sizeof(T)); | ||
volatile int64_t dest; | ||
os::atomic_copy64(reinterpret_cast<const volatile int64_t*>(src), reinterpret_cast<volatile int64_t*>(&dest)); | ||
atomic_copy64(reinterpret_cast<const volatile int64_t*>(src), reinterpret_cast<volatile int64_t*>(&dest)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[pre-existing] Why do we have these casts when atomic_copy64
takes volatile void*
? (There are more like this that I didn't bother to comment directly.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest I don't know :-)
void _Copy_conjoint_jlongs_atomic(const jlong* from, jlong* to, size_t count) { | ||
if (from > to) { | ||
const jlong *end = from + count; | ||
while (from < end) | ||
os::atomic_copy64(from++, to++); | ||
atomic_copy64(from++, to++); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If atomic_copy64
was a shared API with platform-specific implementations we could eliminate all these copies of _Copy_conjoint_jlongs_atomic
.
volatile int32_t *dest); | ||
}; | ||
|
||
extern arm_atomic_funcs _arm_atomic; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is arm_atomic_funcs not an AllStatic class? (And it has a non-conventional name.)
…". Also removed os:: from C_frame_offset on linux/arm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still okay. But I would have resisted making non-move-related changes and leave that for future cleanups.
I have created a new JBS issue ( https://bugs.openjdk.org/browse/JDK-8290745 - Refactor atomic_copy64() functions ) to capture @kimbarrett's comments on the various problems with the atomic copying functions. |
…move-atomic-ops-outside-os-hpp
Thanks to @dholmes-ora and @kimbarrett for the review. Passed build tiers 1 and 5. |
Going to push as commit 2c73a1f. |
The os_xxx.hpp files inject extra methods/fields that are specific to atomic operations into the
os
class. However, the injected methods/fields are used only by a specific os/cpu combination. Therefore, they should not be inside theos
class, which should contain only APIs that are used across platforms.atomic_copy64()
function is used in a single file, I moved it as an inline function in that fileatomic_<os>_<cpu>.hpp
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9501/head:pull/9501
$ git checkout pull/9501
Update a local copy of the PR:
$ git checkout pull/9501
$ git pull https://git.openjdk.org/jdk pull/9501/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 9501
View PR using the GUI difftool:
$ git pr show -t 9501
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9501.diff