The plain write to the value piggybacked on the volatile fence when the
lock is released for guaranteed visibility. However, we should not
assume that visibility is delayed until this fence, as the underlying
system may inject a fence earlier (e.g. safepont, context switch). As
the compiler may change program order for plain reads and writes, those
cases must ensure that there are no dependencies for partial visibility.
While true for strong values, the change in a1a5de8 shows a dependency
order is needed for weak/soft values. For stricter correctness,
clearing the Reference must occur after the entry's value has been
visibly changed. Therefore, the release/acquire ordering is used to
ensure we abide by the Java Memory Model, rather than on x86's total
store order (TSO).

For more details, see
http://gee.cs.oswego.edu/dl/html/j9mm.html

The entry stored the key for normal operations and lifecycle encoding.
The value reference stored because it is returned by the ReferenceQueue
when collected, so the eviction uses the key to remove the entry from
the backing map. Instead the entry can resolve the key through the value
reference rather than storing it twice.

Minimal backport of 1e52b10

This matches the RI's behavior which is best effort.

Backport of 7d0d903

Backport of f143764

This is already documented on the cache loaders for their bulk
loading methods:
```
If the returned map contains extra keys not present in {@code keys}
then all returned entries will be cached, but only the entries for
{@code keys} will be returned from {@code getAll}.
```