How does the dynamic tenuring threshold adjustment work in HotSpot JVM?

Question

So far I know that:

• Objects are allocated in the eden space and if they survive a minor collection they get promoted to one of the survivor spaces
• For further minor collections objects' that survive minor collections are swaped between the two survivor spaces. During this objects' individual ages are increasing with each minor collection.
• Objects that reach a specific tenuring threshold are getting promoted to the tenured space (old generation).
• You can set InitialTenuringThreshold (as it says it is 'initial' and not 'min') and MaxTenuringThreshold (MaxValue: 15). Yet the JVM adjusts the actual tenuring threshold (I think every time after a major collection) in respect to the actually used survivor space and desired survivor space.
• The desired space can be altered using the 'TargetSurvivorRatio' JVM parameter and is by default 50% of the max survivor space.

My Questions are:

• In respect to what exactly does the jvm adjusts the actual tenurig threshold.
• What happens with all the object age queues after the jvm changes the actual tenuring threshold. As for example:
  • timeStamp1: current actual tenuring which was set by the jvm is 15. There are objects distributed in each age.
  • timeStamp2: the jvm has adjusted the actual tenuring threshold to 5. What happens now with all objects with an age of n > 5 from timeStamp1?

Haven't found any documentation on this.

Diorio

Answer 1

I'm very far from an expert on the JDK's codebase but I believe most of your answers will be around the classes I mention. I'm wild guessing from a cursory read, and very glad to hear corrections.

Question 1:

According to http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/gc_implementation/shared/ageTable.cpp L81 and next (compute_tenuring_threshold) the JVM will iterate through each age and add up the size of objects with that age. As soon as it exceeds the desired_survivor_size it'll stop and assume the last age it got to as the candidate new threshold. The chosen new threshold is min(candidateAge, MaxTenuringThreshold)

compute_tenuring_threshold is called in G1 from http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/gc_implementation/shared/g1CollectorPolicy.cpp which choses a _max_survivor_regions based on ceil(_young_list_target_length / SurvivorRatio), then calls the compute_.. method above.

The young_list_target_length is updated in g1CollectorPolicy.hpp as explained:

587   // Update the young list target length either by setting it to the
588   // desired fixed value or by calculating it using G1's pause
589   // prediction model. If no rs_lengths parameter is passed, predict
590   // the RS lengths using the prediction model, otherwise use the
591   // given rs_lengths as the prediction.
592   void update_young_list_target_length(size_t rs_lengths = (size_t) -1);

I didn't look into the model, but I guess this would answer your question: threshold changes are triggered after a lower number of ages is enough to keep the desired_survivor_size (which AFAIK is explained here http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html). The new threshold is chosen based on given / predicted RS lengths.

Question 2:

Check this in g1CollectorPolicy.cpp, right at the start of a new collection pause:

839   // We only need to do this here as the policy will only be applied
840   // to the GC we're about to start. so, no point is calculating this
841   // every time we calculate / recalculate the target young length.
842   update_survivors_policy();

I understand that the threshold will thus be updated before the GC runs. If that's the case, as live objects in survivor regions are visited, all objects that have object.age > newAge will be tenured (including those that had age < threshold at timestamp1 but now exceed it).

I hope that makes a bit of sense.

Hereld