From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 C2C577EE4B for ; Sun, 6 Oct 2013 12:39:17 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of fw@deneb.enyo.de) identity=pra; client-ip=87.106.162.201; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fw@deneb.enyo.de"; x-sender="fw@deneb.enyo.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of fw@deneb.enyo.de) identity=mailfrom; client-ip=87.106.162.201; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fw@deneb.enyo.de"; x-sender="fw@deneb.enyo.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@ka.mail.enyo.de) identity=helo; client-ip=87.106.162.201; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fw@deneb.enyo.de"; x-sender="postmaster@ka.mail.enyo.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKw8UVJXaqLJ/2dsb2JhbABZgwfCIoETFnSCJQEBBAE6PwULCyElDwFHBogTCrsWjhOBPgeEIwOeN4tKgyY6gS0 X-IPAS-Result: AgAFAKw8UVJXaqLJ/2dsb2JhbABZgwfCIoETFnSCJQEBBAE6PwULCyElDwFHBogTCrsWjhOBPgeEIwOeN4tKgyY6gS0 X-IronPort-AV: E=Sophos;i="4.90,1044,1371074400"; d="scan'208";a="29269714" Received: from ka.mail.enyo.de ([87.106.162.201]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 06 Oct 2013 12:39:17 +0200 Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1VSlk2-0003YT-UB; Sun, 06 Oct 2013 12:39:14 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1VSlk2-00034D-QL; Sun, 06 Oct 2013 12:39:14 +0200 From: Florian Weimer To: Yotam Barnoy Cc: Ocaml Mailing List References: Date: Sun, 06 Oct 2013 12:39:14 +0200 In-Reply-To: (Yotam Barnoy's message of "Fri, 27 Sep 2013 10:05:56 -0400") Message-ID: <87bo32heel.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Caml-list] Proposal: re-design of ocaml headers * Yotam Barnoy: > The pfbits (as shown below) are an efficient way of representing both > floats and pointers in a data structure, at the cost of disallowing random > access. From what I can gather, random access to this data is never needed, > since the GC, Marshal module, and polymorphic comparison all process the > whole data structure rather than referring to specific parts of it. I wonder if it could make sense to get rid of polymorphic comparison and make Marshal type-safe before changing the header. If the header is needed for GC only and for telling variants apart, it would not be necessary to discriminate between strings, floats and custom memory blocks in the header. That would give room for 28 bits for the tag/size combination or the string or value array length, with 2 bits used by the GC colors and 2 bits for the type bits (telling apart non-scanned blobs, scanned arrays of values, scanned tagged variants, and unscanned tagged variants). Arrays are separate, so 28 bits should be plenty of room for both tag and variant record length. This way, it would be possible to encode both string and array lengths directly in the header, speeding up bounds checks. The GC would have check the type bits to compute the actual object size from the length in the header, but mutator performance seems more important, and perhaps we can come up with a clever way to decode the length without branching. It might even make sense to store the actual number of elements of a double array in the header, again to speed up bounds checks. If the 32-bit 256 MB string size limit is too onerous, it should be possible to bump it to 512 MB, but that will complicate header decoding further. But it's possible to index only 1 GB, so 256 MB is already pretty close to that hard limit.