[External] : Re: SoV-2: weak references

[Brian Goetz]

On 2/9/2022 1:23 PM, Kevin Bourrillion wrote:
> This is not based on a very deep understanding, sorry:
>
> * WeakReference, 1-arg constructor: When given a bucket 2-or-3 
> instance, it seems maybe fine to just treat as strong reference? User 
> is saying "just hold this loosely, don't keep it alive on my account" 
> and doesn't care what happens after that.

This is *sometimes* what the user wants.  And one could argue that for a 
"pure" value (values all the way down), this is the right answer.  But 
suppose a value holds an identity:

     value class ListHolder {
         List<String> list = new ArrayList<>(1_000_000);
     }

If the user does

     ListHolder lh = new ListHolder<>();
     WR<ListHolder> wr = new WR(lh);

there are conditions under which lh.list becomes unreachable -- but 
retaining the WR forever means it is never GCed.  Some users will find 
this surprising, and say "but I used a WR to avoid memory leaks."  So 
there's an argument that WR is really just about feeding reachability 
information back from the GC to the application, and the GC only talks 
about reachability for identities.

Picking a one-size-fits-all policy like "always clear / never clear" 
means that WR will do the right thing sometimes, and the wrong thing 
other times.

> * For WeakHashMap use cases, I would expect that any attempts to 
> actually design something "good" that does what users really "want" 
> would end up at some different library entirely. This is something 
> that Caffeine 
> <https://urldefense.com/v3/__https://www.javadoc.io/doc/com.github.ben-manes.caffeine/caffeine/2.0.3/com/github/benmanes/caffeine/cache/Caffeine.html__;!!ACWV5N9M2RV99hQ!aAeubPGvWWVNvDUogPbhs3-S8pqBfMYAF8m2ApoI9cCzEQB4-_yNVg6K0RMaRWHYJQ$> 
> probably does well (disclosure, I worked on the thing that became that).

Yes, probably.  We're worried about existing applications that are built 
around WHM, and trying to give them something reasonable that will keep 
them going, since many of these are legacy applications with limited 
room for rearchitecting.  So we're asking "what's the least we have to 
do", and the simple set of policies I outlined for WHM is a candidate.