The purpose of this RFE is to add an enhancement to the java.lang.ref
APIs that enables java.util.WeakHashMap bug 4429536 to be fixed (as
well as similar problems to be solvable for other data structures that
use weak references).

Obvious requirements of any such enhancement include:

- The new behavior must be practical to implement over the wide range
  of known and forseeable virtual machine and garbage collector
  implementations.

- The API addition should fit nicely within the spirit of the existing
  java.lang.ref package.

Below is one proposal for such an enhancement.  There are certainly
many imaginable variations on this proposal that would also satisfy the
goal and requirements of this RFE to a greater or lesser degree; I
chose to submit this one to start the discussion with (see the Comments
section for some further discussion.  The feature is called something
like "joined weak references":

	Say that I have two weak reference objects (probably
	java.lang.ref.WeakReference instances) that have different
	referents:

		weakrefA -> A		weakrefB -> B

	I would like to designate that weakrefB must not be cleared
	unless weakrefA has either already been cleared or is being
	cleared at apparently the same time (i.e. atomically with
	respect to weakrefA's clearing).  All other rules for weak
	references still apply.

	(If the restriction had to be narrowed so that weakrefA and
	weakrefB simply must be cleared together atomically, then that
	would probably be OK too.)

	API-wise, this would probably be done with additional
	constructors to WeakReference that took another WeakReference
	for the new instance to be "joined" to.  Unfortunately, this
	would require doubling the number of WeakReference constructors
	from two to four (because null cannot be used to register with
	no ReferenceQueue).

To review the problem of 4429536: consider a weak (hash) map for which
there is a possibility that the key of an entry might be strongly
reachable (however indirectly) from its value.  Typical weak map
implementations like java.util.WeakHashMap use a weak reference to hold
the key and a strong reference to hold the value, and thus the "weak"
aspect of the map will be ruined for entries in which this possibility
actually occurs.  (See the Comments section of 4429536 for a workaround
that is possible today, but has considerable drawbacks.)

If the weak map entry used weakrefA to hold the key (A) and weakrefB to
hold the value (B), and if weakrefB were joined to weakrefA as
described above, then I think that this problem would be solved.  When
an entry's key is strongly reachable from its value, then both weakrefA
and weakrefB would need to be cleared together, just like if they were
not "joined".  But most importantly, the joined aspect will keep the
value alive as long as the key is alive (at least weakly reachable)
*without* the value itself pinning the key.