Feedback from experiments on production application

[Aleksey Shipilev]

On 05/09/2018 10:27 PM, Roman Kennke wrote:
> Hi Petr,
> 
> thanks for running the experiments with newer builds again.
> 
> I guess the class unloading problem can currently only be 'solved' by
> disabling it with -XX:ShenandoahUnloadClassesFrequency=0, which should
> be ok if your application doesn't use much classloaders. However, be
> aware that app servers then to make fairly heavy use of classloaders.
> And then there is also anonymous classes (and related stuff like
> lambdas) which are not obvious but also put pressure on the class unloading.

So maybe we can fix it radically: make class unloading opt-in, rather than opt-out with
-XX:+UseShenandoahGC? Pending jdk/jdk work is supposed to make class unloading concurrent, and we
can make it opt-out again at that point. It seems unwise to throw low-latency users under the bus
like this. (Milder alternative: disable class unloading for concurrent cycles, but leave it for STW)

Thanks,
-Aleksey