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 4B8567ED99 for ; Tue, 26 May 2015 17:42:27 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mshinwell@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="mshinwell@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mshinwell@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="mshinwell@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsAQDGkmRVnHDIaSZcg2ReBoMZsSOQRIV3AoE/BzwQAQEBAQEBAREBAQEBAQYWCU+EIwEBBBIRHQEBLAsBDwsLDQICCR0CAiEBEgEFAQoSBhMIChCHdQMSAwqjUT4xik5whGQBBZloAwqFBgEBAQEBAQQBAQEBAQEBAQETBgqBF4oZgk2BZgEBUAeCaIFFhU8KkWmFAYFZgSk+hjKIE4U5EiOBFYIJJByBU26BDIE7AQEB X-IPAS-Result: A0BsAQDGkmRVnHDIaSZcg2ReBoMZsSOQRIV3AoE/BzwQAQEBAQEBAREBAQEBAQYWCU+EIwEBBBIRHQEBLAsBDwsLDQICCR0CAiEBEgEFAQoSBhMIChCHdQMSAwqjUT4xik5whGQBBZloAwqFBgEBAQEBAQQBAQEBAQEBAQETBgqBF4oZgk2BZgEBUAeCaIFFhU8KkWmFAYFZgSk+hjKIE4U5EiOBFYIJJByBU26BDIE7AQEB X-IronPort-AV: E=Sophos;i="5.13,499,1427752800"; d="scan'208";a="127864786" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2015 17:42:26 +0200 Received: from tot-qpr-mailcore2.delacy.com ([172.27.56.106] helo=tot-qpr-mailcore2) by mxout1.mail.janestreet.com with smtp (Exim 4.82) (envelope-from ) id 1YxGzo-0001RW-O0 for caml-list@inria.fr; Tue, 26 May 2015 11:42:24 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore2 with JS-mailcore (0.1) (envelope-from ) id BVZJRg-AAAGLh-Wd; 2015-05-26 11:42:24.719921-04:00 Received: from mail-oi0-f49.google.com ([209.85.218.49]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1YxGzo-0002w0-IS for caml-list@inria.fr; Tue, 26 May 2015 11:42:24 -0400 Received: by oihd6 with SMTP id d6so80875918oih.2 for ; Tue, 26 May 2015 08:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rrYD7JrZkgqb/ITU9pvAG8WC/gCpdJJKtYrgRlDLZvA=; b=bA1bTrnR1hvGYZ5wmmWJ4oR6HkSwKun4VWExu7kVah2lx4mwVQ6YR1zDz3QfnRBiue gXAbPk7iSubSPy8EFZi+XaybVUqnnxJRpQs0lxfYQJvujkVVroMAV9Yn5XBYRNfCQq7H 7iiY7q5a1mD+vfNiAEshY6OzMXnJxJbYi4c5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rrYD7JrZkgqb/ITU9pvAG8WC/gCpdJJKtYrgRlDLZvA=; b=dVY7b7F9zM2a4eWz+md27kTq8Sni0G9R+UZOcSTv7zcVt9erbvIjz126eYNMWS4EnQ mIAPKREs+5clsNczdvVXzB4Ml6kBL92vG4edpKBLJ6yjbf35XcD0GIB8uJmTs9wk96QU xzAWpVokNtr0xGIWjpcJHEA/RWZjZYYhMkwOyGx24Aew6mtGNjP8BQ3SomTZAPOw1dr6 Ja+HuaapIG+m/hrCrgUo30pH9DJit1r6JJK2yUInnRhGuR10UTa7xZIr4izPlZUMSOEy wf4XmP43bIYbuVoOkQ6QwFl8KN/xlkx6htrDWnANQdg+6HmElPj83XGarbb4ByI6R0TN an2Q== X-Gm-Message-State: ALoCoQmtxKhX7+RMkP68avD/+JjFgGhmqeqa36jR5J9Q3XMO/De1GD+JdYcAiZ8Gwdmk8+M1MUI0X6hac/9fjQi0hcqMLNWTYa3z4Vv5u1c/JT2IAOQ5FRYTyeZQeGIxm7LFNnxoP5qD X-Received: by 10.60.62.105 with SMTP id x9mr22116952oer.1.1432654944205; Tue, 26 May 2015 08:42:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.62.105 with SMTP id x9mr22116944oer.1.1432654944064; Tue, 26 May 2015 08:42:24 -0700 (PDT) Received: by 10.202.107.209 with HTTP; Tue, 26 May 2015 08:42:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 May 2015 16:42:23 +0100 Message-ID: From:Mark Shinwell To:Fabrice Le Fessant Cc:Jez , Ocaml Mailing List Content-Type: text/plain; charset=UTF-8 X-JS-Processed-by: mailcore X-Validation-by: mshinwell@janestreet.com Subject: Re: [Caml-list] When to (not) use -no-naked-pointers? A bit more detail following on from Fabrice's mail. A "naked pointer" is traditionally used to describe a non-immediate value that is scanned by the GC and points outside the OCaml heap. However, in the context of the "-no-naked-pointers" configuration option, there is a more specific meaning. When the system is configured in this mode any naked pointer (an undesirable thing in any case) must be dereferenceable without a fault and point at a block that has the basic structure of an OCaml value. In particular, there must be a valid header one word prior. Such headers should be coloured black; if they are in read-only memory, they must be coloured black. These restrictions enable the page table test to be suppressed when scanning all values except closures, which may improve performance under high GC pressure. As an aside, there is a bug in the debug runtime in the released compiler system that causes an assertion to fail when "-no-naked-pointers" was specified in conjunction with "-runtime-variant d". This will be fixed in 4.02.2. Mark On 25 May 2015 at 22:49, Fabrice Le Fessant wrote: > Hi, > > Naked pointers only appear in C bindings when pointers to C > structures are passed directly as OCaml values. Non-naked pointers are > the ones which are hidden within either a custom block or a block with > the "abstract" tag (Tag_abstract). It is normally easy to modify a > binding to switch from naked-pointers to non-naked pointers (it could > even be a configure script option of the binding). The only case where > there is a (big) problem is when the binding is allocating OCaml > values outside of the heap: it is the case for the "ancient" library, > for example, that copies OCaml values outside of the heap to avoid > garbage collections; it is also the case for some bindings that create > OCaml string headers in front of C buffers, to be able to manipulate > them directly in OCaml (I did that once to share OCaml strings between > processes, using shared memory). > > --Fabrice > INRIA &OCamlPro > > > On Mon, May 25, 2015 at 8:25 AM, Jez wrote: >> Hi, >> >> I noticed that 4.02 now has the no-naked-pointers option. I'd like to better >> understand when I shouldn't use it -- i.e. what kinds of operations create >> naked pointers? I suppose that these pointers can only be generated by C >> code; an example of when their use may arise would be nice :) >> >> Jez > > > > -- > Fabrice LE FESSANT > Chercheur en Informatique > INRIA Paris Rocquencourt -- OCamlPro > Programming Languages and Distributed Systems > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs