Re: [Caml-list] segfault in simple program with 4.02 native

[Martin Jambon <martin.jambon@ens-lyon.org>]

On 09/05/2014 11:00 PM, 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.

I remember considering this solution in the past. It seems it would work.

I must say there's a strange feeling about creating more type 
definitions while breaking the type system.

> On Sat, Sep 6, 2014 at 1:51 AM, Martin Jambon
> <martin.jambon@ens-lyon.org> wrote:
>> On Fri 05 Sep 2014 05:12:44 PM PDT, Jeremy Yallop wrote:
>>>
>>> On 6 September 2014 00:39, Martin Jambon <martin.jambon@ens-lyon.org>
>>> 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 <field name> = 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