Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8235362

Possible markWord performance issue on Windows

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P4 P4
    • tbd
    • 14
    • hotspot
    • None
    • gc

      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.

            Unassigned Unassigned
            kbarrett Kim Barrett
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: