Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd like to use org.agrona as a stable home for ReferenceHelper. The JavaDoc explains its purpose to some degree, but let me elaborate here:
There is currently a deficiency in the Java Reference class API (which I would like to suggest fixes to over time via a JEP): Two common operation idioms that are used in most WeakReference-based data structured can currently only be performed by using a Reference.get(), which explicitly creates a strong reference to the referent and can prevent its collection on concurrent collectors. The two operations are isCleared() (usually done by evaluating (ref.get() == null) and isReferingTo (usually done by evaluating (ref.get() == obj)). Examples of these operations can be seen in e.g. WeakIdentityHashMap and ThreadLocal.ThreadLocalMap. Both of these are examples of how the forced use of Reference.get() to perform a non-reference-escaping operation leads most concurrent collectors (G1, C4, ZGC, Shenandoah) to keep such tables massively populated with weakly-keyed items that would have properly died if it were not for this strengthening during concurrent marking. While both of these examples are in-JDK implementations, similar data structures outside the JDK exist, which are exposed to the same issues. ReferenceHelper introduces two methods (one for each idiom) that do not expose the underlying referent, thereby allowing intrinsic implementations that would not force-strengthen the referent when called.
My aim with ReferenceHelper in agrona is three-fold:
Provide a stable, well-documented API that can be intrinsified by JDKs, such that (when the API is used on an intrisifying JDK) unnecessary strengthening is avoided.
Make the case for adding Reference.isCleared() and Reference.isReferingTo() to future OpenJDK versions, by supplying working implementation examples of common data structure, using org.agrona.ReferenceHelper APIs in the same way that the proposed APIs would be used.
Provide a cross-JDK-version compatible API (similar to what org.agrona.hints.ThreadHints.onSpinWait() does), such that data structures written to this new API will work on both older and newer JDKs, but would be able to benefit from the better (not explicitly stregthening) behavior of future JDK versions or of inrisifying JDKs of current versions.