-
Enhancement
-
Resolution: Withdrawn
-
P4
-
None
-
8-shenandoah, 11-shenandoah, 13, 14, 15
-
generic
-
generic
Shenandoah uses SATB for concurrent marking, and thus needs to track stores and explicitely make previous values grey. An exception to this is are (soft/weak/final) references: the reachability of referents can be changed (from weak to strong) when a referent is accessed. For this reason we require a keep-alive barrier which also makes referents grey whenever they are accessed via Reference.get(). The downside of this is if a workload churns weak-references (i.e. accesses them often) they might never get a chance to be reclaimed.
The key insight for improving the situation is that the change of reachability of the referent is only relevant when that referent is stored somewhere else. We can elide the keep-alive barrier, if the compiler can prove that this doesn't happen. (We also need to check if the referent leaves the scope of the method via method-call or return, because it may be stored outside of the method.) The caveat here is that we must do another scan of the threads' stacks at final-mark to catch referents that are in a local variable at final-mark - we must not loose those. However, according to my measurements, this is only a minor (if any) regression in final-mark-latency.
The key insight for improving the situation is that the change of reachability of the referent is only relevant when that referent is stored somewhere else. We can elide the keep-alive barrier, if the compiler can prove that this doesn't happen. (We also need to check if the referent leaves the scope of the method via method-call or return, because it may be stored outside of the method.) The caveat here is that we must do another scan of the threads' stacks at final-mark to catch referents that are in a local variable at final-mark - we must not loose those. However, according to my measurements, this is only a minor (if any) regression in final-mark-latency.