caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Josh Berdine <josh@berdine.net>
To: "Caml-list" <caml-list@inria.fr>
Subject: [Caml-list] Expected behavior of Weak hash tables
Date: Wed, 10 Jul 2013 00:05:15 +0100	[thread overview]
Message-ID: <87d2qr5o7o.fsf@berdine.net> (raw)

Hi,

I am using the standard library's Weak hash tables for what I expect is
a pretty standard hash-consing implementation.  I wonder if I should
expect the implementation of Weak.Make to guarantee that elements of the
weak set disappear _only_after_ they become dead.  That is, can live
values that are members of a weak set be removed from the set by the
garbage collector?  I have tracked down some unexpected behavior
(e.g. non-maximal sharing) in my code to what looks like this premature
disappearance from a weak set.  I have only observed live values
disappear from the weak set after a major collection, and I think only
when the heap has been grown.  This behavior is very fragile and
seems to be extremely sensitive to very slight changes to the program,
and I can't say for certain at this point that my code is doing exactly
what it should.

So my question is: Am I expecting the implementation of Weak.Make to
satisfy a stronger property than it is intended to, or should I continue
hunting the bug in my code?  And also, does anyone have suggestions for
good approaches to debugging this sort of very allocation-sensitive
behavior?

In case they are relevant, some additional details:

- The values which are unexpectedly not members of the weak set are not
  the shallow copies of elements that are passed to the H.equal
  relation.

- The elements of the weak set have no finalizers, from either the C or
  OCaml APIs.

- The elements of the weak set may have cyclic substructures, but there
  are no cycles through a weak set element.  However, I observe the
  strange behavior even for very simple entirely acyclic immutable
  values.

- The type of elements of the weak set is hidden behind a private type
  to all of the code but ~10 lines, so there is little opportunity to
  make the usual sort of mistake of constructing shallow copies of weak
  set elements that are not themselves in the set.  Also, the only
  values of this type ever constructed are returned by Weak.Make.merge,
  and the clear, add, and remove operations are not used.

- This is with OCaml 4.00.1, using either the 32-bit MSVC Windows port
  or 64-bit Linux, although it seems to happen more often on the former.
  I tried with trunk, but the fix for PR#6005 seems to require
  significant changes to my code.  (But, no, I'm not exploiting PR#6005
  to define magic.)

Cheers, Josh

             reply	other threads:[~2013-07-09 23:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-09 23:05 Josh Berdine [this message]
2013-07-10  7:21 ` Jacques-Henri Jourdan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d2qr5o7o.fsf@berdine.net \
    --to=josh@berdine.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).