I got a crash running JBB under the collector.
On inspection of the crash log, I found that the code in forte.cpp which validates the Lmethod of an interpreter frame is not cautious enough.

static inline bool forte_is_valid_method(methodOop method) {
  if (method == NULL ||
      // The methodOop is extracted via an offset from the current
      // interpreter frame. With AsyncGetCallTrace() the interpreter
      // frame may still be under construction so we need to make
      // sure that we got an aligned oop before we try to use it.
      !Space::is_aligned(method) ||
      !Universe::heap()->is_in_reserved((void*)method) ||
      // See if GC became active after we entered AsyncGetCallTrace()
      // and before we try to use the methodOop. This routine is
      // used in validation of the top_frame so we don't have any
      // other data to flush if we bail due to GC here.
      // Yes, there is still a window after this check and before
      // we use methodOop below, but we can't lock out GC so that
      // has to be an acceptable risk.
      Universe::heap()->is_gc_active() ||
      // klass() does not need vtable dispatch so check before is_perm()
      oop(method)->klass() != Universe::methodKlassObj() ||
      !method->is_perm() ||
      !method->is_method()) {
    return false; // doesn't look good
  }
  return true; // hopefully this is a method indeed
}

In the above method, the is_perm call must come before the klass check.

If not, you can get a method pointing into the unmapped part of the heap's reserved area (e.g., a very high address just within bounds), and the instruction which loads the class will SEGV. This is what happened to me.

(You should remove the comment about a vtable, which appears to be a thoughtless and useless optimization. Nobody cares which order the tests come in, since in most cases both tests are going to be run, since most frame collection attempts are successful.)