FastSyncRoots and monitor deflation question

[Roman Kennke]

I just checked some code around monitor handling in Shenandoah.

I see this looks odd:

    if (ShenandoahFastSyncRoots && MonitorInUseLists) {
      if
(_process_strong_tasks->try_claim_task(SHENANDOAH_RP_PS_ObjectSynchronizer_oops_do))
{
        ObjectSynchronizer::oops_do(strong_roots);
      }
    } else {
      while(_om_iterator.parallel_oops_do(strong_roots));
    }

ShenandoahFastSyncRoot is true by default, but it turns on the
*single-threaded* path? Is that intentional? If this is really better
than the parallel stuff, then maybe remove the parallel stuff?

I also see this stuff:

  experimental(bool, ShenandoahMergeSafepointCleanup, false,
   \
              "Do safepoint cleanup piggy-backed on thread scans")
   \

   \
  experimental(uint, ParallelSafepointCleanupThreads, 0,
   \
          "Number of parallel threads used for safepoint cleanup")
   \

   \


I.e. our improvements (if they are) to safepoint cleanup are turned off
by default, and thus probably totally untested. Do we know if it
actually helps? Would it be worth turning on by default so that it gets
testing? Otherwise remove/revert the corresponding code changes and
wait/work-on concurrent monitor deflation?


Roman