Request for review: 6521376: MaxTenuringThreshold and AlwayTenure/NeverTenure consistency

[Thomas Schatzl]

Hi,

On Tue, 2013-07-02 at 14:13 -0700, Tao Mao wrote:
> new webrev:
> http://cr.openjdk.java.net/~tamao/6521376/webrev.02/
>
>On 6/24/13 6:50 AM, Thomas Schatzl wrote: 
> > Hi,
> > 
> > On Sat, 2013-06-22 at 20:03 -0700, Tao Mao wrote:
> > > 6521376: MaxTenuringThreshold and AlwayTenure/NeverTenure consistency
>>
> > Some notes:

>>- the change does not maintain consistency of MaxTenuringThreshold
>> with the InitialTenuringThreshold variable.
> > Running the VM with -XX:InitialTenuringThreshold=5 -XX:+AlwaysTenure
> > will give an error (note that InitialTT is set before AlwaysTenure); the
> > other way the VM should give an error.
> The most recent gc repo behavior:
> $java -XX:InitialTenuringThreshold=5 -XX:+AlwaysTenure -version
>
>
> I don't see any need to sync ITT and MTT in other silent way.

The syncing is actually already done. Ie.

$ ../bin/java -XX:+AlwaysTenure -XX:+PrintTenuringDistribution -XX:
+PrintFlagsFinal -jar dacapo.jar eclipse | grep InitialTen

gives

    uintx InitialTenuringThreshold                 := 0
{product}           

with your latest changes. I was worried that the output of -XX:
+PrintFlagsFinal showed an inconsistency. It does not, so this concern
can be put aside. -XX:+PrintFlagsFinal is an interface to the outside
after all.

As for the particular case (ITT=5, +AlwaysTenure and +AlwaysTenure,
ITT=5) I tried to find other combinations of switches that do some
silent synching, but it seems I misremembered. I rest my case :)

> > > *******************************************************************************
> > > Take a little convoluted case for example: suppose that we have the 
> > > following gc options "-XX:+NeverTenure -XX:+MaxTenuringThreshold=18" in 
> > > this particular order.
> > > 
> > > When we first parse "-XX:+NeverTenure", we would set: NeverTenure=true; 
> > > AlwaysTenure=false;  MaxTenuringThreshold=16.
> > > 
> > > But when we encounter the second option "-XX:+MaxTenuringThreshold=18", 
> > > we would think the user knows about gc ergonomics for tenuring threshold 
> > > and wants MaxTenuringThreshold to just be a cap for the ergonomics 
> > > rather than wants to (implicitly) use NeverTenure. So, we would set 
> > > NeverTenure=false; AlwaysTenure=false; and finally 
> > > MaxTenuringThreshold=16 to reflect the cap maximum.
> > > *******************************************************************************

The behavior in the last paragraph and sentence ("... and finally
MTT=16") is what I did not understand.
The description indicated (to me) that setting the MTT=18 after the
+NeverTenure set MTT to 16 so that the VM continues to run.

Also, your description does not seem to match how the VM actually acts.
I.e.

../bin/java -XX:MaxTenuringThreshold=18 -version
MaxTenuringThreshold of 18 is invalid; must be between 0 and 16
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

and

$ ../bin/java -XX:+NeverTenure -XX:MaxTenuringThreshold=18 -version
MaxTenuringThreshold of 18 is invalid; must be between 0 and 16
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

This is exactly what I would have expected, not what has been written in
the example.

I am looking forward to the test cases for this change - because they
are less ambiguous and less prone to omission and errors when done well.

The VM change itself looks good now.

Thanks,
Thomas