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

G1: Keep BOT _next_offset_index in sync with humongous regions' top

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P5
    • Resolution: Duplicate
    • Affects Version/s: 17
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
      gc

      Description

      During discussions of JDK-8264783 the question came up why we need to use MIN2 in the calculation of the last BOT entry to scan.

      I.e. in G1BlockOffsetTablePart::verify() there is the code:

        size_t end_card = MIN2(_bot->index_for(_hr->top() - 1), _next_offset_index - 1);

      The reason is that particularly for humongous regions we do not sync top() and _next_offset_index.

      The reason is that when we calculate the BOT for these regions G1BlockOffsetTablePart::set_for_starts_humongous() we do not know what top ends up being - memory visibility issues wrt to concurrent refinement require that at that point the top of these regions must be equal to bottom() (see the comments around the call in G1CollectedHeap::humongous_obj_allocate_initialize_regions()).

      There is also the problem that we can't use end() for these regions (afaict) because we can end up with an unparseable tail at the end.

      Fixing this up after completed allocation of the humongous object could be an option, but seems too much effort for just this case (i.e. adding comparatively much code for the only gain that this assert would be simpler).

      Investigate this a bit further, maybe there is a good way to allow this anyway.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              tschatzl Thomas Schatzl
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: