Please implement client switch in 64-bit server JDK 14 builds

[John Rose]

On Aug 7, 2019, at 1:49 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> The problem is to some extent that Java sizes itself based on the
> machine that it is running on. If it sees plenty of memory and threads
> it uses them, in an attempt to improve performance.
> 
> I think you should be able to achieve some similar results to -client
> by trying -XX:TieredStopAtLevel=1 and sizing the heap appropriately
> for your application. There is also a bunch of GC settings which cause
> it to be very frugal with memory. These together will, I suspect, be
> more effective than the old "-client" option.
> 
> In general, I think we do need a "-small" option for the JVM. The GC
> defaults are inappropriate for a lot of applications. However, I'm not
> exactly sure what "-small" should be.

This is a hard problem, since any additional switch we add will almost
certainly have an unstable impact (behavior, meaning) across releases
and platforms.  Somehow users would have to be coaxed to use a combo
switch like “-small” as a starting point, rather than a final solution.

(We’ve had switches like this before, such as AggressiveOpts, which
is deprecated in part because it has no stable meaning.)

That said, I have one idea to add to the conversation:  If we are already
setting flags ergonomically based on machine size, a somewhat conservative
thing to do is to allow another switch or dial that alters the apparent size of
the platform, as observed by ergonomic logic (Arguments::apply_ergo).
(Think of it as like a golf handicap, to make a strong player look like a
weaker one?)

Note that the JVM settings after ergo logic can be observed with the
switch -XX:+PrintCommandLineFlags, which (to me) is confusingly similar
to -XX:+PrintVMOptions.  A reasonable thing to do if you are sizing JVMs
would be to run on the target machine with -XX:+PrintCommandLineFlags
and use the displayed values as a starting point for further tuning.
This is true today, and also would be true if we allowed machine sizing
adjuster.

So, if the above is reasonable, then some flags affecting machine
size sensing might make sense.  And, in fact, there are such flags
already, such as -XX:+NeverActAsServerClassMachine.

-XX:CompileThresholdScaling is also such a scaling flag, although
it interacts with a fixed compilation policy.

(BTW, it’s probably an interesting exercise to troll through the sources
looking at all the uses of FLAG_SET_ERGO, and figuring out what
they really mean and how they might be made more tweakable along
the lines of a “-small” switch.)

Another aspect of “-small” is minimum values.  Some use cases may
want to say “give me 2x the minimum” instead of “give me 50% of the
machine”.  There are minimums today such as CodeCacheMinimumUseSpace
which are set on a per-platform basis.

Putting it together, maybe gross sizing could be controlled as a rough multiplier,
such as 1..9 (qualitative, as with zip) or a (quantitative) percentage, to be applied
either to the minimum setting or the maximum.  The default is then “100% of maximum”.
Setting to “1 x minimum”, followed by PrintCommandLineFlags and OS information
displays, would allow operators a somewhat smoother way to detect the minimum and
use that information to size JVMs and their host machines.

But I’ll end where I started:  Such combo switches tends to be unpleasant to maintain,
because their meaning must shift over time, and so (I think) they never really please
the end users.

My $0.02.

— John