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 3AE617FACB for ; Sat, 6 Sep 2014 21:15:53 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of martin.jambon@ens-lyon.org) identity=pra; client-ip=66.111.4.25; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of martin.jambon@ens-lyon.org does not assert whether or not 66.111.4.25 is permitted sender) identity=mailfrom; client-ip=66.111.4.25; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; 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@out1-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.25; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="postmaster@out1-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4BAMpcC1RCbwQZnGdsb2JhbAA/GoNgV4I0SLAxhDSRc4dMAYEAFhABAQEBAQYNCQkUKYQDAQEEAQwXBAsBBQguCgIECwkCGAICBQQSCwICCQMCAQIBMxITBgIBAQ6IHAMJCA02i1KbTXiFCIkUA4ZkAREGgSyOKIJ5gVOFDwWGJocMgy+CPIYlhUgakWxMAYJOAQEB X-IPAS-Result: Av4BAMpcC1RCbwQZnGdsb2JhbAA/GoNgV4I0SLAxhDSRc4dMAYEAFhABAQEBAQYNCQkUKYQDAQEEAQwXBAsBBQguCgIECwkCGAICBQQSCwICCQMCAQIBMxITBgIBAQ6IHAMJCA02i1KbTXiFCIkUA4ZkAREGgSyOKIJ5gVOFDwWGJocMgy+CPIYlhUgakWxMAYJOAQEB X-IronPort-AV: E=Sophos;i="5.04,479,1406584800"; d="scan'208";a="77996973" Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2014 21:15:52 +0200 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id 5A3F2206EB for ; Sat, 6 Sep 2014 15:15:51 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Sat, 06 Sep 2014 15:15:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=/AzZxduaRbvjxeOKSr+vQH Sy6YY=; b=HPIXZb/NqT+s/lwGqD2YwuZR+zDEl1fQFf4bdUx0I1NKsHcX1kQ3Nu E7Fqtyg7FphoneRhtvCnVvCIdVEk/fYMXvZ1LVurpwmijBKeUES69YaQKi3AKdL2 62sdVT8AQEb8lBbRG4uhlVAxSSnb/4fsD3KUod8I7gJZrPd4UAoRU= X-Sasl-enc: f4Vhuap/kxwfKX/i1o5cdHtasueT50ogJ2vhF3JT0XBo 1410030951 Received: from [192.168.2.7] (unknown [67.180.86.2]) by mail.messagingengine.com (Postfix) with ESMTPA id EC1AF6800B8 for ; Sat, 6 Sep 2014 15:15:50 -0400 (EDT) Message-ID: <540B5D66.9060700@ens-lyon.org> Date: Sat, 06 Sep 2014 12:15:50 -0700 From: Martin Jambon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <20140905215626.GB3416@annexia.org> <20140905221302.GE3099@annexia.org> <20140905221813.GC3416@annexia.org> <540A3B85.6010609@ens-lyon.org> <540AA0DB.1040202@ens-lyon.org> <540ABBED.8080307@lakaban.net> In-Reply-To: <540ABBED.8080307@lakaban.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] segfault in simple program with 4.02 native On 09/06/2014 12:46 AM, Frédéric Bour wrote: > Since it is generated code and offsets of the fields are already known, > Obj.new_block / Obj.set_field / Obj.repr could do it too. > The Obj.repr will be the only point were the typed version is introduced > and it won't receive any mutation after that, this should be enough to > make it works. I'd love to do that. The reason why it's not implemented this way right now is that all-float records use a different representation than other records. Atdgen would need to know when such a representation is chosen by the OCaml compilers. This may a problem with field types that are abstract to atdgen but not to OCaml. I have to think about it. > Of course, this might not be robust against future changes. > > On 06/09/2014 10:00, Milan Stanojević wrote: >> Could you do a dirty trick where you define a record that is the same >> as the one you have now except that is has mutable fields, then you do >> your parsing like now and then at the end return a record with >> immutable fields (using (Obj.magic mutable : immutable)? You just need >> to make sure that your mutable record doesn't escape your code. >> >> On Sat, Sep 6, 2014 at 1:51 AM, Martin Jambon >> wrote: >>> On Fri 05 Sep 2014 05:12:44 PM PDT, Jeremy Yallop wrote: >>>> On 6 September 2014 00:39, Martin Jambon >>>> wrote: >>>>> That code is generated by atdgen. What happens is that we have to >>>>> either >>>>> create an empty record when starting to parse a list of unordered JSON >>>>> fields, or use a bunch `let = ref None in` for each field >>>>> and >>>>> create the record in the end. While the latter approach is not much >>>>> more >>>>> work to implement, the resulting code was found to be significantly >>>>> slower. >>>>> >>>>> The reason why it's using `Obj.magic 0.0` is that it worked in all >>>>> cases >>>>> (and has been for the past 4 years). Obtaining a well-formed constant >>>>> value >>>>> for any type is not trivial, so this what we have. >>>>> >>>>> It's very possible that it's now broken with OCaml 4.02. First try a >>>>> 'make >>>>> test' from atdgen's source directory >>>>> (https://github.com/mjambon/atdgen) >>>>> and >>>>> see if it passes. >>>> >>>> It does seem to be broken, and the change in behaviour with 4.0.2 is >>>> apparently due to improved constant propagation >>>> (http://caml.inria.fr/mantis/view.php?id=5779). >>>> >>>> The compiler now takes more advantage of immutability to improve the >>>> memory usage and performance of programs. It's safe (or ought to be >>>> safe) to assume that immutable record fields are never updated, so the >>>> values used to initialize the fields can be propagated to other parts >>>> of the program. Here's a small example that shows the change in >>>> behaviour between 4.01 and 4.02. >>>> >>>> type t = { s : string } >>>> let x = { s = "one" } >>>> let () = Obj.(set_field (repr x) 0 (repr "two")) >>>> let () = print_endline x.s >>>> >>>> Using OCaml 4.01 the third line overwrites the field 's' and the >>>> fourth line reads the updated field and prints "two". Using OCaml >>>> 4.02 the initial value of the field is propagated past the write to >>>> the code in the fourth line, so the program prints "one". >>>> >>>> The code currently generated by atdgen assumes that it's safe to treat >>>> fields as if they were mutable -- that is, it assumes that it's safe >>>> to initialize a field with a value of the wrong type, so long as the >>>> value is overwritten before the field is first read. I don't think >>>> such tricks were ever explicitly guaranteed to work, but they're now >>>> much more likely to fail, leading to the dummy initial value being >>>> accessed at an inappropriate type. >>> >>> Thanks for the explanation, Jeremy. I guess atdgen will have to use >>> "option >>> refs" after all unless someone has a better idea. >>> >>> ATD definition: >>> >>> type t = { >>> ?field0: foo option; >>> ~field1: string; >>> field2: int; >>> } >>> >>> Generated OCaml code: >>> >>> let field0 = ref None in >>> let field1 = ref "" in >>> let field2 = ref None in >>> ... >>> (* parse json fields coming in an unknown order *) >>> ... >>> { >>> field0 = !field0; >>> field1 = !field1; >>> field2 = (match !field2 with None -> error ... | Some x - >x); >>> >>> } >>> >>> >>> -- >>> 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 > >