markWord was reimplemented as a thin wrapper class over a uintptr_t by JDK-8229258. The "thin wrapper" idiom used there works well on some platforms (specifically non-ancient UNIX ABI calling conventions), but doesn't meet the requirements for a performant thin wrapper on Windows. For Windows, such a thin wrapper class still needs to be POD; the UNIX calling conventions only require a trivial copy ctor and destructor.
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions?view=vs-2019
A possible fix for markWord might be to add a public factory function that is used by clients instead of the constructor, plus some Windows conditionalization in the class, e.g. something like
class markWord {
WINDOWS_ONLY(public:)
uintptr_t _value;
#ifndef _WINDOWS
explicit markWord(uintptr_t value) : _value(value) {}
markWord() { /* uninitialized */ }
#endif // _WINDOWS
public:
static markWord make() { return markWord(); }
static markWord make(uintptr_t value) { return markWord(value); }
...
};
Note that somewhat similar classes like MemRegion (JDK-8218192) apparently lose on Windows even if POD, because the Windows calling conventions don't permit a multi-word object to be spread across multiple registers.
It might be that there is sufficient inlining to make the calling convention largely moot though.
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions?view=vs-2019
A possible fix for markWord might be to add a public factory function that is used by clients instead of the constructor, plus some Windows conditionalization in the class, e.g. something like
class markWord {
WINDOWS_ONLY(public:)
uintptr_t _value;
#ifndef _WINDOWS
explicit markWord(uintptr_t value) : _value(value) {}
markWord() { /* uninitialized */ }
#endif // _WINDOWS
public:
static markWord make() { return markWord(); }
static markWord make(uintptr_t value) { return markWord(value); }
...
};
Note that somewhat similar classes like MemRegion (
It might be that there is sufficient inlining to make the calling convention largely moot though.
- relates to
-
JDK-8218192 Remove copy constructor for MemRegion
-
- Resolved
-
-
JDK-8229258 Rework markOop and markOopDesc into a simpler mark word value carrier
-
- Resolved
-