From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id DA26981792 for ; Wed, 10 Jul 2013 01:05:21 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of josh@berdine.net) identity=pra; client-ip=66.111.4.25; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="josh@berdine.net"; x-sender="josh@berdine.net"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of josh@berdine.net) identity=mailfrom; client-ip=66.111.4.25; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="josh@berdine.net"; x-sender="josh@berdine.net"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@out1-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.25; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="josh@berdine.net"; x-sender="postmaster@out1-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMBAD+W3FFCbwQZk2dsb2JhbABbsywBkwYWDgEBAQEHCwsJFAQkgmoyCDs0ASwNAROIIgSoBIRHjUgGFpNQjD2SL41G X-IPAS-Result: AuMBAD+W3FFCbwQZk2dsb2JhbABbsywBkwYWDgEBAQEHCwsJFAQkgmoyCDs0ASwNAROIIgSoBIRHjUgGFpNQjD2SL41G X-IronPort-AV: E=Sophos;i="4.87,1031,1363129200"; d="scan'208";a="20575821" Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 10 Jul 2013 01:05:20 +0200 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AFEE021032; Tue, 9 Jul 2013 19:05:18 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 09 Jul 2013 19:05:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=berdine.net; h= from:to:subject:date:message-id:mime-version:content-type; s= mesmtp; bh=O/UVQUMJFXpHbA1tp4JRYo/Kqwo=; b=X6MAyUPglsiu2yrpCZ7J1 P5r9jytyEAdLlIyvcjEyRVIGWMGJIgVF6kDQqNfc2DqphQFkFK9TxHdICuVE1P6N PUcJmHahx6Yc+FjGSfG63rG5KbkxOJIGYyryfuj3ykJ2FB+NMbnWeu0iniENdEKK 7Ju36lDSdRUF10VuSlUruY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:to:subject:date:message-id :mime-version:content-type; s=smtpout; bh=O/UVQUMJFXpHbA1tp4JRYo /Kqwo=; b=gmA0xBIlFASsc2Ch18Yte8XxOLTPHCIs+ctj6WPP5gi/a38QhKhr19 qWG2deO/ngDnbrt+XHuYCQxj7926s3giqACylU1p0uvyr3HCDw7b9nD/qRh1d3ov I9PJBRqrPErQuW+eS983uE9ifkKd4RG//lZ72fMJEUgSUAc6+EfrA= X-Sasl-enc: JY4TA9uMaNJe6ZhLICKIuNfoEi8uGFRNm3BWhadviv6f 1373411116 Received: from locust (unknown [82.27.236.146]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F2FDC00E91 for ; Tue, 9 Jul 2013 19:05:16 -0400 (EDT) Received: from jjb by locust with local (Exim 4.76) (envelope-from ) id 1UwgyB-0001WK-IJ for caml-list@inria.fr; Wed, 10 Jul 2013 00:05:15 +0100 From: Josh Berdine To: "Caml-list" Date: Wed, 10 Jul 2013 00:05:15 +0100 Message-ID: <87d2qr5o7o.fsf@berdine.net> MIME-Version: 1.0 Content-Type: text/plain Subject: [Caml-list] Expected behavior of Weak hash tables 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