From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTPS id 5588C5D4 for ; Thu, 20 Dec 2018 09:46:45 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,376,1539640800"; d="scan'208,217";a="361193860" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 20 Dec 2018 10:46:44 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 4C1F682567; Thu, 20 Dec 2018 10:46:44 +0100 (CET) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 8285A824CF for ; Thu, 20 Dec 2018 10:46:40 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=stephen.dolan@cl.cam.ac.uk; spf=None smtp.mailfrom=stedolan@stedolan.net; spf=None smtp.helo=postmaster@mail-wr1-f53.google.com IronPort-PHdr: =?us-ascii?q?9a23=3A1b6ZohTH0RTsCa02ehwimLvqTNpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa69bB2N2/xhgRfzUJnB7Loc0qyK6/CmATRIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSizexfbB/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf?= =?us-ascii?q?5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbD?= =?us-ascii?q?VwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0li?= =?us-ascii?q?gIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRODYOy?= =?us-ascii?q?bYQBD+QPM+VFoYfju1QDtgGxCRW2Ce711jNEmn370Ksn2OohCwHG2wkgEsoTvn?= =?us-ascii?q?TIstr1LKcSXv6zzKLVwzvDaPdW1i376IPVdR0huu2MUqxoccrR10YvERnJgUiX?= =?us-ascii?q?qYzhJTyV0P8AvHSf7+Z6Se2gkWsnpxtrrTez3Mssl4rJi5sTx1vZ9it52J44Kc?= =?us-ascii?q?OkREN/e9KpE5tduzuEO4doX88uWWFltSg8x7Ybo5C0ZjIKx44ixxPHa/yIbYyI?= =?us-ascii?q?4hX7WeaUOzh4hXZldKuxhhao7ESs0+P8W8m63VpQoSpFld7Mtn8J1xPN8MSIVv?= =?us-ascii?q?x9/kK51TaO0QDc9P1ELFgqmabHL5Mt2L09m5oJvUjdACP6hV/6ga+Ye0k8/+in?= =?us-ascii?q?8eXnYrHopp+GMI90jxnzMr8ymsOhHOs4NQwOUHKd+emnz73j4VP2T6hNjv0yiK?= =?us-ascii?q?bZtorWJcIFqa6lGwNVyJos6w6jDze619QVhWUII0hAeBKDloTpP1DOIOvkDfqk?= =?us-ascii?q?mFStkDJrx+jcMbH7A5XNKGLDkLb7crpn5U5c0ll78dcKw5NSBqoIMbreQFXwst?= =?us-ascii?q?PECRlxZwi1xer8AcQ725kEWGSAHqifGKzXuF6MoOkoJr/fSpUSvWPGN/U95/Po?= =?us-ascii?q?xVM+nVYbNf2ywZYPaH2+WPhhJ0yfSXHoxNwIFCEDtUwjT7q52xW5TTdPaiPqDO?= =?us-ascii?q?oH7TYhBdfjVN+bH9H/sPm6xC6+W6ZuSCVDA1GIH23vctzYCewQZS6VJsZn1DoJ?= =?us-ascii?q?Ser5EtNz5VSVrAb/joFfAK/M4CRB6cDo0J5+7uiVnBp06D8mV53AgVHIdHl9my?= =?us-ascii?q?YzfxFz3K17phYgmFKK0Kw9nOYBUNIOvLVGVQA1MZOaxOt/WYj/?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAQBJZBtcgDXdVdFjHgEGBwaBZYNsJ?= =?us-ascii?q?4N9gR2SeIINiRWIbYdXDIdZGgYGNBIBAwEBAgEBAQEBEwEBCQ0JCCcxgjYkAYJ?= =?us-ascii?q?iAQQBI1YFCwkCBAc3AgIhARIBBQEcBhOFDAMNCIwRkAg8ixmBL4gCDSsfgVMSj?= =?us-ascii?q?C2BVz+EI4JXhTKCVwKJJ4Y1kS4zBwKCJQSMCoMyGJFcj1mKIw8hgTyBdzMaND8?= =?us-ascii?q?xBoI1kFtCMI5nAQE?= X-IPAS-Result: =?us-ascii?q?A0DXAQBJZBtcgDXdVdFjHgEGBwaBZYNsJ4N9gR2SeIINiRW?= =?us-ascii?q?IbYdXDIdZGgYGNBIBAwEBAgEBAQEBEwEBCQ0JCCcxgjYkAYJiAQQBI1YFCwkCB?= =?us-ascii?q?Ac3AgIhARIBBQEcBhOFDAMNCIwRkAg8ixmBL4gCDSsfgVMSjC2BVz+EI4JXhTK?= =?us-ascii?q?CVwKJJ4Y1kS4zBwKCJQSMCoMyGJFcj1mKIw8hgTyBdzMaND8xBoI1kFtCMI5nA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.56,376,1539640800"; d="scan'208,217";a="361193811" Received: from mail-wr1-f53.google.com ([209.85.221.53]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Dec 2018 10:46:39 +0100 Received: by mail-wr1-f53.google.com with SMTP id t27so1011509wra.6 for ; Thu, 20 Dec 2018 01:46:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0HiUVQ2iMVU2BD/K9R9GEbB/Wm53UUju436dBfeim5E=; b=W3ncLR7djI99d6oN9q/vFGUIauBum3ivMR1/6364R2WTBRG5XS87mlKwYuo16JETl8 /Kt/oWBgTULsGZfaqIY15oui0vvKF6kiskf1neR+/cpAORxobpD3CwYAmAAY8onxp6LW qp4hhXqqvw+CAvBvB38DrmYpXGEO8NZs6FrBlc7AVIrh9ZhNSnVqh2eJiuOsWc8IOuA5 Qs3bj50cKBtHz7RYUHyQQRotmZY0kveKTXP/rXGyHdzEH6Tpt1e9QEQPYrmQNjWGY1HA 6EF5nSL7S+5kPkOrAUlFH/QCg0cEME9qnwY2C1VuNF1mXMvl4ht47Gxcbvu8U0GRCRHM 53iA== X-Gm-Message-State: AA+aEWb+NLWB62YwIKtJfEViwt17Yfqn+Kv1+8WG8CPYxXtbntQVQ2wU gpK9BrFa0BtQY0iAFkO3K2aJFyAg1GyK6XcLn3QG6D9IMv1zJw== X-Google-Smtp-Source: AFSGD/Uj4mLPNnCVqD06Su1fkkxL17yHeEr0dt0POASdEQnQns1YZiQWHimrfVZsE6TEq8PC9ER+QrRNq8oNphzeq9U= X-Received: by 2002:adf:c846:: with SMTP id e6mr21067893wrh.243.1545299198829; Thu, 20 Dec 2018 01:46:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stephen Dolan Date: Thu, 20 Dec 2018 09:46:27 +0000 Message-ID: To: Lindsay Errington Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary="000000000000d17ab6057d71017c" Subject: Re: [Caml-list] Possible ephemeron bug? Reply-To: Stephen Dolan X-Loop: caml-list@inria.fr X-Sequence: 17254 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000d17ab6057d71017c Content-Type: text/plain; charset="UTF-8" On Thu, 20 Dec 2018 at 00:30, Lindsay Errington wrote: > If however, I use the standalone bytecode compiler or the native compiler > (4.07.1), then the entries are not nullified. Is this a bug or is there > another way to persuade the garbage collector to clobber the entries? > Thanks for the detailed example! The issue is with the test code at the end: let (root,map) = let map = [] in let (k0,map) = intern 0 (str 1) map in let (k1,map) = intern 1 (Link k0) map in let (k2,map) = intern 2 (Link k1) map in (k2,map);; Fmt.printf "root=%a, map=@[%a@]@." pp_key root pp_map map;; let map = upd root (str 2) map;; Fmt.printf "root=%a map1=@[%a@]@." pp_key root pp_map map;; Both the bytecode and native code compilers take any value bound to a global to be reachable forever, even if that global is later shadowed by another global of the same name. The ephemerons don't get cleared, because the original map is still alive. You can change the code to avoid putting the original map in a global constant: let (root, map) = let map = [] in let (k0,map) = intern 0 (str 1) map in let (k1,map) = intern 1 (Link k0) map in let (k2,map) = intern 2 (Link k1) map in Fmt.printf "root=%a, map=@[%a@]@." pp_key k2 pp_map map; let map = upd k2 (str 2) map in (k2, map);; Fmt.printf "root=%a map1=@[%a@]@." pp_key root pp_map map;; With this version, the original map becomes unreachable, so the GC can clear the ephemerons. Stephen -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list Forum: https://discuss.ocaml.org/ Bug reports: http://caml.inria.fr/bin/caml-bugs --000000000000d17ab6057d71017c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu,= 20 Dec 2018 at 00:30, Lindsay Errington <lindsay.errington@gmail.com> wrote:
If however, I use the standalone bytecode compiler or the= native compiler (4.07.1), then the entries are not nullified. Is this a bu= g or is there another way to persuade the garbage collector to clobber the = entries?

Thanks for the detaile= d example!

The issue is with the test code at the = end:

=C2=A0 =C2=A0 let (root,map) =3D
=C2=A0 =C2=A0 =C2=A0 let map =3D [] in
=C2=A0 =C2=A0 =C2=A0 le= t (k0,map) =3D intern 0 (str 1) map in
=C2=A0 =C2=A0 =C2=A0 let (= k1,map) =3D intern 1 (Link k0) map in
=C2=A0 =C2=A0 =C2=A0 let (k= 2,map) =3D intern 2 (Link k1) map in
=C2=A0 =C2=A0 =C2=A0 (k2,map= );;
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 Fmt.printf "= root=3D%a, map=3D@[<v>%a@]@." pp_key root pp_map map;;
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 let map =3D upd root (str 2) m= ap;;
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 Fmt.printf "= ;root=3D%a map1=3D@[<v>%a@]@." pp_key root pp_map map;;

Both the bytecode and native code compilers take any= value bound to a global to be reachable forever, even if that global is la= ter shadowed by another global of the same name. The ephemerons don't g= et cleared, because the original map is still alive.

You can change the code to avoid putting the original map in a global co= nstant:

=C2=A0 =C2=A0 let (root, map) =3D
=C2=A0 =C2=A0 =C2=A0 let map =3D [] in
=C2=A0 =C2=A0 =C2= =A0 let (k0,map) =3D intern 0 (str 1) map in
=C2=A0 =C2=A0 =C2=A0= let (k1,map) =3D intern 1 (Link k0) map in
=C2=A0 =C2=A0 =C2=A0 = let (k2,map) =3D intern 2 (Link k1) map in
=C2=A0 =C2=A0 =C2=A0 F= mt.printf "root=3D%a, map=3D@[<v>%a@]@." pp_key k2 pp_map m= ap;
=C2=A0 =C2=A0 =C2=A0 let map =3D upd k2 (str 2) map in
<= div>=C2=A0 =C2=A0 =C2=A0 (k2, map);;
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0
=C2=A0 =C2=A0 Fmt.printf "root=3D%a map1=3D@[<v>= ;%a@]@." pp_key root pp_map map;;

With = this version, the original map becomes unreachable, so the GC can clear the= ephemerons.

Stephen
--000000000000d17ab6057d71017c--