No class unloading by default?

Roman Kennke rkennke at redhat.com
Fri Oct 26 02:00:32 UTC 2018


I was just scratching my head why I would see (expensive) string table
scanning during init-mark even when explicitely setting
ShenandoahUnloadClassesFrequency=1. This should actually never go to
StringTable stuff.

Then I saw that we disable class unloading by default:

  if (!ClassUnloadingWithConcurrentMark) {
    FLAG_SET_DEFAULT(ShenandoahUnloadClassesFrequency, 0);
  }

I also see this:
  // If class unloading is disabled, no unloading for concurrent cycles
as well.
  // If class unloading is enabled, users should opt-in for unloading during
  // concurrent cycles.
  if (!ClassUnloading ||
!FLAG_IS_CMDLINE(ClassUnloadingWithConcurrentMark)) {
    log_info(gc)("Consider -XX:+ClassUnloadingWithConcurrentMark if
large pause times "
                 "are observed on class-unloading sensitive workloads");
    FLAG_SET_DEFAULT(ClassUnloadingWithConcurrentMark, false);
  }

I believe we should not disable 'conc' class unloading by default. This
seems just wrong. It means that we're risking to pile up classes and
lots of auxiliary stuff like strings unless we run into full-gc which we
hope that we never have to do. Piling up that stuff means to negatively
impact our pause times. (Yes I know, class unloading also negatively
impacts pause times, but...) How is this setting justified?

Roman



More information about the shenandoah-dev mailing list