TenuringThreshold being adaptive when UseAdaptiveSizePolicy is off

[Kirk Pepperdine]

Hi Jon,

Slightly off topic.

This question triggered me to once again take a closer look at psAdaptiveSizePolicy and CMSAdaptiveSizePolicy. What I saw is that

uint PSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold(
                                             bool is_survivor_overflow,
                                             uint tenuring_threshold,
                                             size_t survivor_limit) {

and

uint CMSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold(
                                             bool is_survivor_overflow,
                                             uint tenuring_threshold,
                                             size_t survivor_limit) {

are cut and paste copies of each other. In fact the amount of common code in both classes suggests they were a complete cut and paste copy of each other. Yes there are a couple of minor differences but not enough to warrant two separate classes. It’s also a bit scary to see this level of cut and paste in the JVM source code. Maybe it was intentional, if so it should have been justified with a comment but … I’ll say no more on this topic.

As I’ve mentioned before, AdaptiveSize can get into this degenerative pathological condition in low free heap conditions. It starts with higher GC frequencies slowing the allocation rates from the mutator threads. These lower allocation rates when feed back into adaptive sizing, are a signal to shrink the size of heap which is exactly the opposite of what you’d like to see in this condition. I have offered to work on a patch to fix this but I’ve been told by several people that they have a patch to correct this behavior so no need to do so.

My question is, can we get one of these patches released so that we can correct this behavior?

Kind regards,
Kirk

On Mar 10, 2015, at 7:07 AM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:

> 
> On 3/9/2015 10:39 PM, Jungwoo Ha wrote:
>> We were investigating some features and figured out that ParallelScavange and ParNew has different TenuringTreshold heuristics.
>> We thought it would be nice to have a flag that can control the adaptiveness, so that we can fix it on purpose to isolate other performance factors.
> 
> Do you use UsePSAdaptiveSurvivorSizePolicy to turn off the 
> survivor space resizing and tenuring threshold adaptiveness
> for ParallelGC?
> 
> Jon
> 
>> --Jungwoo
>> 
>> On Mon, Mar 9, 2015 at 11:27 AM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>> Jungwoo,
>> 
>> On 03/06/2015 06:03 PM, Jungwoo Ha wrote:
>>> I think it is the same for all JDK{7,8,9}.
>>> 
>>> arguments.cpp disabled UseAdaptiveSizePolicy for CMS.
>>> parallel scavange initializes _tenuring_threshold with
>>>   _tenuring_threshold = (UseAdaptiveSizePolicy) ? InitialTenuringThreshold : MaxTenuringThreshold;
>>> whereas CMS uses
>>>   _tenuring_threshold = MaxTenuringThreshold;
>>> 
>>> adjust_desired_tenuring_threshold() is called inside ParNewGeneration::collect(), which calls compute_tenuring_threshold.
>>> It only uses MaxTenuringThreshold and TargetSurvivorRatio.
>>> I don't see any other flags here.
>> 
>> Yes, this is the intended behavior.
>> 
>> You're saying we're sometimes wasting survivor space?
>> 
>> Jon
>> 
>>> 
>>> On Fri, Mar 6, 2015 at 4:28 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>>> This is in jdk9?
>>> 
>>> Jon
>>> 
>>> 
>>> On 3/6/2015 4:21 PM, Jungwoo Ha wrote:
>>> On CMS when UseAdaptiveSizePolicy is off, still tenuring_threshold is being changed.
>>> Is this an intended behavior?
>>> (yes. I know it is not "size" related heuristics)
>>> 
>>> It would be nice to have a flag that can disable adjusting tenuring threshold,
>>> or at least set minimum threshold. When the default heuristics doesn't work,
>>> there are nothing much we can do other than changing the Max.
>>> 
>>> --Jungwoo
>>> 
>>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150310/56e8c436/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150310/56e8c436/signature.asc>