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

Zero: CASE(_new) should replenish TLABs properly

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 8, 11, 15, 16
    • Fix Version/s: 16
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b25

      Description

      If you look at how current CASE(_new) is structured, then you will notice an odd thing:

                if (ik->is_initialized() && ik->can_be_fastpath_allocated() ) {
                  size_t obj_size = ik->size_helper();
                  oop result = NULL;
                  if (UseTLAB) {
                    result = (oop) THREAD->tlab().allocate(obj_size);
                  }
                  if (result == NULL) {
                     // allocate from inline contiguous alloc
                  }
                  if (result != NULL) {
                     // initialize the object and return
                 }
                }
              }
              // Slow case allocation
              CALL_VM(InterpreterRuntime::_new(THREAD, METHOD->constants(), index),
                      handle_exception);
              // return
       
      The oddity here is: when TLAB is depleted and rejects the allocation, we fall through to inline contiguous alloc block that allocates the object in shared eden. That allocation is likely to succeed, and then we return from this path. But TLAB would never get replenished! Because to do that, we need to hit the slowpath allocation in Interpreter::_new, let in enter the runtime, and ask GC for a new TLAB!

      So in the end, when +UseTLAB is enabled for Zero, the code only uses the very first issued TLAB, and then always falls through to inline contiguous allocation, until eden is completely depleted. Inline contiguous block makes the shared CAS increment that could be heavily contended under allocations.

      I have observed this with supplying +UseTLAB to my adhoc Zero runs -- it was still slow. I think we can just remove the inline contiguous allocation block, and let the whole thing slide to slowpath on failure. This would also resolve the issue of enabling Zero for GCs that do not support inline contiguous allocs (anything beyond Serial and Parallel).

      Sample allocation benchmark:
       - original: 302 +- 5 ns/op
       - original +UseTLAB: 291 +- 5 ns/op
       - patched +UseTLAB: 233 +- 3 ns/op

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              shade Aleksey Shipilev
              Reporter:
              shade Aleksey Shipilev
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: