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

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

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
>> <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
>
>