RFR (XXS): 8247748: Use default alpha for G1 adaptive IHOP allocation rate calculation

[Thomas Schatzl]

Hi,

On 18.06.20 21:18, Thomas Schatzl wrote:
> Hi,
> 
> On 18.06.20 20:45, Luo, Ziyi wrote:
>> Hi Thomas,
>>
>> I am a little bit confused here.
>>
>> According to the TruncatedSeq constructor, the alpha is used to construct
>> AbsSeq:
>> http://hg.openjdk.java.net/jdk/jdk/file/08211be640e9/src/hotspot/share/utilities/numberSeq.cpp#l31 
>>
>>
>> When adding a new value to AbsSeq, the weight of the new val is (1.0 - 
>> _alpha):
>> http://hg.openjdk.java.net/jdk/jdk/file/08211be640e9/src/hotspot/share/utilities/numberSeq.cpp#l146 
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/08211be640e9/src/hotspot/share/utilities/numberSeq.cpp#l44 
>>
>>
>> Right now, in Adaptive IHOP, the weight of the new value is (1-0.95) =
>> 0.05. After changing alpha to the default 0.7, the weight is increased 
>> to 0.3,
>> which actually emphasizes the most recent allocation rate and will 
>> potentially
>> make the prediction spikier.
>>
> 
>    you are right. I mostly went with my memory  which apparently has 
> been the complete opposite of what it does/did, which led to the CR 
> title/description :(
> 
> In my tests I could not see an actual difference in behavior so I 
> figured it would be better to not deviate from the other, existing 
> predictors instead of some other number as we do not have any 
> explanation for the default value (of 0.7) either. I.e. something like 
> "one magic number is better than two".
> 
> For this (very weak) reason I would still like to make this change, but 
> I am open to just retract this change.
> 
> Thanks for making me aware of this!

   just let me retract this RFR for now. I will take more time to find a 
better reasoning for any change in that area.

Thanks,
   Thomas