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

[Ty Young]

On 8/8/19 1:53 PM, Andrew Haley wrote:
> On 8/8/19 9:23 AM, Ty Young wrote:
>> Presumably these standards would just be meta JVM arguments that could
>> be done manually with individual JVM arguments. If an end JVM user wants
>> a bit more max memory size for example, they could just manually set Xmx
>> to their desired amount and keep the rest of the mode JVM arguments as
>> they are. Something like:
>>
>> -XX:VMMemoryManagementMode=0 // server mode?
>>
>> -XX:VMMemoryManagementMode=1 // desktop application mode?
>>
>> -XX:VMMemoryManagementMode=2 // IoT/Kiosk application mode?
> Funnily enough, I was talking to John Rose the other day and he
> suggested exactly this, but perhaps a scale from 0-10. This idea has
> some promise, I think.
>

Ah, no those numbers aren't part of a scale and personally I don't think 
using a scale is a good idea. If you do a hard 0-10 scale you are 
backing yourself into a corner when the standards of today change.


Remember when 32-bit was assumed to be more than we'd ever need? Or the 
Y2K non-crisis?


You could change the scale internally at a later date, sure, but then 
you'd presumably wind up making people who depended on the old scale 
meanings a bit upset. I guess they'd be using an older JDK but still... 
it'd be nice if this wasn't yet another thing people needed to look out 
for when upgrading JDK versions.


So maybe something like:


-XX:VMMemoryManagementMode=00000 // server mode?

-XX:VMMemoryManagementMode=10000 // desktop application mode?

-XX:VMMemoryManagementMode=20000 // IoT/Kiosk application mode?



The first number in the 5th position represents a mode type while the 
remaining 4 numbers represent iterations of that mode type. The idea 
here is that new iterations of a spec can be added on later. For 
example, 00000 represents a server spec as it would be defined today. 
If, in the future, that changes at all, a new server spec can be made 
like: 00001. This also makes these mode iterations opt-in instead of a 
"fun" little surprise people have to look out for every JDK release.


If there are more than 9999 iterations of a spec mode then I guess that 
mode type could be expanded into the next free mode type position(4, 5, 
6, etc).


I can imagine this getting to become very unmaintainable in such a 
situation to the point that you JVM people will start banging your heads 
against a wall... so maybe a more maintainable solution could be made 
based off of this?