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

Thomas Schatzl thomas.schatzl at oracle.com
Thu Jun 18 19:25:44 UTC 2020


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.


More information about the hotspot-gc-dev mailing list