From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alain@frisch.fr>
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 D55327EE4B
	for <caml-list@sympa.inria.fr>; Thu,  3 Oct 2013 22:52:47 +0200 (CEST)
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  alain@frisch.fr) identity=pra; client-ip=212.27.42.2;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr";
  x-conformance=sidf_compatible
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  alain@frisch.fr) identity=mailfrom; client-ip=212.27.42.2;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr";
  x-conformance=sidf_compatible
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@smtp2-g21.free.fr) identity=helo;
  client-ip=212.27.42.2;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="alain@frisch.fr";
  x-sender="postmaster@smtp2-g21.free.fr";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmUBAL3YTVLUGyoCnGdsb2JhbABZhzm7JIJ7gRwWDgEBAQEBBg0JCRQogiUBAQUjDwEFQAEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAYgGqiWSRYEpjigHgmqBOQOYAYY1jnA
X-IPAS-Result: AmUBAL3YTVLUGyoCnGdsb2JhbABZhzm7JIJ7gRwWDgEBAQEBBg0JCRQogiUBAQUjDwEFQAEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAYgGqiWSRYEpjigHgmqBOQOYAYY1jnA
X-IronPort-AV: E=Sophos;i="4.90,1028,1371074400"; 
   d="scan'208";a="29029580"
Received: from smtp2-g21.free.fr ([212.27.42.2])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Oct 2013 22:52:46 +0200
Received: from [192.168.0.10] (unknown [78.192.0.38])
	by smtp2-g21.free.fr (Postfix) with ESMTP id 9E7BB4B00F4;
	Thu,  3 Oct 2013 22:52:42 +0200 (CEST)
Message-ID: <524DD919.7070604@frisch.fr>
Date: Thu, 03 Oct 2013 22:52:41 +0200
From: Alain Frisch <alain@frisch.fr>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?UTF-8?B?TWlsYW4gU3Rhbm9qZXZpxIc=?= <milanst@gmail.com>
CC: Caml List <caml-list@inria.fr>
References: <CAKR7PS_7qKvQUx1tm2DaSJWZG-viDhfbdRLTrYB1yxE=Vq6Upw@mail.gmail.com> <524DAD23.7070206@frisch.fr> <CAKR7PS9SBXJUak76btS63C8Avk5yWo=8ZnrNfdv2-XLmU8zbdg@mail.gmail.com>
In-Reply-To: <CAKR7PS9SBXJUak76btS63C8Avk5yWo=8ZnrNfdv2-XLmU8zbdg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Caml-list] empty mli for executable

On 10/3/2013 8:42 PM, Milan Stanojević wrote:
> Thanks, Alain.
> Just one question about this. Let's say I have a toplevel value in my
> executable and an empty mli. How is this toplevel value then retained?
> Is it part of some other root set ?

Well, actually, after double-checking, it appears that in native code, 
the non-exported values are still stored in the global record 
corresponding to the unit.  See this comment in translmod.ml:

    Identifiers that are not exported are assigned positions at the
    end of the block (beyond the positions of all exported idents).


This is just one possible compilation strategy, designed to reduce 
pressure on registers (and it invalidates my explanation).  Another one 
would be to simply consider those value as local variables (in 
registers, maybe spilled to the stack).

The current strategy has the effect that a non-exported toplevel value 
is never reclaimed by the GC, even if it is no longer accessible (this 
is not the case in bytecode).


Alain