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
8295146: Clean up native code with newer C/C++ language features #11081
Changes from all commits
e668fa4
212299e
a0808e4
eebe53b
daf5522
83ed3de
53062d9
629a36a
7f00d5e
f46497b
06ffe35
d1b358e
2a80644
ee8cc63
9ea05d6
1a63cff
f42f257
e5f0ea4
5f1ed98
86908cf
1c576fb
027a0ac
43406aa
f16109e
9252f15
c49f0b9
63a2fa5
9ac2a54
d4edc9e
e8744fb
f190f05
bab3add
55001a4
7eec82b
3e1d1be
54b41b0
5d19718
73a6e38
9ab0af7
31970b9
50e4223
b8ed539
f2e3c72
ffec8b0
c43f955
61bddd1
48e262c
0a05374
fbeae3f
2d7c562
0f02174
fb9ecb6
b55071a
2bf475f
6027331
e72b9b1
4d8b710
05b31ea
26b120e
85f6d91
7ba5a7d
5e4bbd0
6d85c43
bb3ef0d
fe5371c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,6 +32,8 @@ | |
class outputStream; | ||
class Thread; | ||
|
||
static unsigned __stdcall thread_native_entry(Thread*); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I follow, I didn't remove anything here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry my eyes must be playing tricks on me. ?? Why did you need to add this here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11:
While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Digging into this some more, the friend declaration exists to provide access to the private One obvious and cheap solution to that would be to make that enum public. I think that would be an improvement vs the current friend declaration. But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used. Here's a patch that I think cleans this up.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The issue with that would be that thread_native_entry is declared as static to the compilation unit on other other Operating Systems as well, and having it as a static member on the win32 class instead would end up breaking this convention, for which I'm not sure if there's a reason why all of them are declared like this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The thread entry functions are expected to be plain C functions as we use C library calls to create threads ( |
||
|
||
typedef void (*signal_handler_t)(int); | ||
|
||
class os::win32 { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -479,8 +479,8 @@ class FileMapInfo : public CHeapObj<mtInternal> { | |
bool remap_shared_readonly_as_readwrite(); | ||
|
||
// Errors. | ||
static void fail_stop(const char *msg, ...) ATTRIBUTE_PRINTF(1, 2); | ||
static void fail_continue(const char *msg, ...) ATTRIBUTE_PRINTF(1, 2); | ||
ATTRIBUTE_PRINTF(1, 2) static void fail_stop(const char *msg, ...); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again I suggest a newline after |
||
ATTRIBUTE_PRINTF(1, 2) static void fail_continue(const char *msg, ...); | ||
static bool memory_mapping_failed() { | ||
CDS_ONLY(return _memory_mapping_failed;) | ||
NOT_CDS(return false;) | ||
|
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.
So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right?
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.
Yep, just something that C++ does a little neater, at least in my view
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.
We (the HotSpot Group) have not discussed or approved the use of the new C++ attribute syntax, whether for standard attributes or compiler-specific ones. That involves an update to the Style Guide. I'm not convinced switching existing uses from compiler-specific
__attribute__
syntax to compiler-specific[[attribute]]
syntax is worth the substantial code churn.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.
I was under the assumption that anything not listed under "Not discussed" or "Forbidden" was free game in HotSpot, I apologise for my goof since that isn't the case. That said, I am curious if there are any isolated conversations about the attribute syntax anywhere
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.
@kimbarrett Aside from the attribute syntax (which you're already doing in a new proposal), now that
alignas
has been approved for use in HotSpot, is there anything that can be done for 8250269: Replace ATTRIBUTE_ALIGNED with alignas and the related Pull Request (https://git.openjdk.org/jdk/pull/11431)?