#7 Docs should mention tombstoning 2


(Sorry, sf.net does not have a way to re-open issues. Don't shoot the messenger. :)

See https://sourceforge.net/tracker/?func=detail&aid=2828100&group_id=194172&atid=948362 for original report.

Cliff, you misunderstood my report. The problem is that only values are tombstoned; keys references are still kept around. See attached Test.java -- invoking set._map.print(set._map._kvs) (via a debugger, sorry I didn't think it warranted writing out using reflection to get to the private fields) results in

10 (BigStuff@a31e1b,tombstone)
11 (BigStuff@17ce4e7,tombstone)
12 (BigStuff@62937c,tombstone)
17 (BigStuff@e1d5ea,tombstone)
22 (BigStuff@15a0305,tombstone)
25 (BigStuff@c88440,tombstone)
26 (BigStuff@10da5eb,tombstone)
27 (BigStuff@765a16,tombstone)
28 (BigStuff@7c4c51,tombstone)
31 (BigStuff@1081d2e,tombstone)

so the keys (set values) are still around and not GC-able.


  • Jonathan Ellis

    Jonathan Ellis - 2009-08-11
  • Cliff Click

    Cliff Click - 2009-08-14

    Got it. This is somewhat more of a problem; I cannot remove a key and let that array slot be reused because of a race between writing a new key/value and an olde reader. I can completely kill slots, although is not efficient if the same key is inserted & removed repeatedly.

  • Cliff Click

    Cliff Click - 2009-08-14
    • assigned_to: nobody --> cliffclick
    • status: open --> open-accepted
  • Jonathan Ellis

    Jonathan Ellis - 2009-08-14

    Sure, it's definitely expected that there are tradeoffs involved. IMO it mostly just needs to be documented.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks