Current MarkBitMap::clear_range calls to BitMap::clear_range, which ends up doing this:

inline void BitMap::clear_range_of_words(bm_word_t* map, idx_t beg, idx_t end) {
  for (idx_t i = beg; i < end; ++i) map[i] = 0;
}

While modern compilers are good at recognizing this idiom as bulk clearing, we should not rely on this in performance-critical code paths. Even when such substitution is made, it is usually limited to release builds only, and having a faster fastdebug builds would be a plus. Older compilers may not enable this substitution by default. Build system may opt out of linkage against stdlib memset.

There is BitMap::clear_range_large we can call instead, for example:
 http://cr.openjdk.java.net/~shade/8213373/webrev.00/

This is the port of Shenandoah change:
 http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-January/001564.html