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.