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
next 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