JDK-8235362 : Possible markWord performance issue on Windows
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 14
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-12-04
  • Updated: 2019-12-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Description
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.