Possible markWord performance issue on Windows

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.