Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4630118

(ref) Add joined weak references / weak properties



    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 1.4.0
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Understanding:
      Fix Understood
    • CPU:
    • OS:


      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

      - 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

      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.


          Issue Links



              mr Mark Reinhold
              peterjones Peter Jones
              0 Vote for this issue
              2 Start watching this issue