No class unloading by default?

[Roman Kennke]

And this, of course, only raises the question why should string table
handling+cleaning be tied to class unloading to begin with? This seems
to be a somewhat random artifact of us extracting ParallelCleaning out
of G1. Let me see if I can come up with something better.

Roman

> 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
>