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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 27FA37EEBF for ; Sat, 11 Jul 2015 00:16:07 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.213.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.213.178 as permitted sender) identity=mailfrom; client-ip=209.85.213.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ig0-f178.google.com) identity=helo; client-ip=209.85.213.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AgCDQ6BVlLLVVdFbgzE1YAaDGqhtjnqCKIU7OgKBPgdMAQEBAQEBEgEBAQEHCwsJHzCEJAEBAgEBEhEdARsSCwEDAQsGBQsaHQICIQEBEQEFAQoSBhMICgIOh3YBAwoIDatTgSw+MYs/gWuCeYsYChknAwpXhQEBAQEBAQUBAQEBAQEBARQBBQ6LPYJNgjUEB4JogUMFhV0MhzKHFoRphTWBZoIEj0SFWRIjgRURBoQZLzEBAYJJAQEB X-IPAS-Result: A0D6AgCDQ6BVlLLVVdFbgzE1YAaDGqhtjnqCKIU7OgKBPgdMAQEBAQEBEgEBAQEHCwsJHzCEJAEBAgEBEhEdARsSCwEDAQsGBQsaHQICIQEBEQEFAQoSBhMICgIOh3YBAwoIDatTgSw+MYs/gWuCeYsYChknAwpXhQEBAQEBAQUBAQEBAQEBARQBBQ6LPYJNgjUEB4JogUMFhV0MhzKHFoRphTWBZoIEj0SFWRIjgRURBoQZLzEBAYJJAQEB X-IronPort-AV: E=Sophos;i="5.15,450,1432591200"; d="scan'208";a="169823281" Received: from mail-ig0-f178.google.com ([209.85.213.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Jul 2015 00:16:06 +0200 Received: by igpy18 with SMTP id y18so22743669igp.0 for ; Fri, 10 Jul 2015 15:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kDnSE+LAZX6nKdsC2YlZTRAmEtwMWJ2avMCmdu9zTT4=; b=viWMBSt5YfPEU+yzdpqxmaFx2pMQltUguNCT2gCT/5CFH0KlR52cd/gZ5ht881xfn4 I/UjKSa+ck7vLIufFvq620WJg5fZomIKw43gqWsnwkUn+C1mT8BM2GMmlvE+D9gGGKKI HF2AjcaCQRWjRF+4ht/8u00IDUnnadd9NF3mpnJuqSPofu4U1aBtICWpN1C8lbSV2EuQ IvEvv2sl3lySy6YFhKLkVxAuWwUsnjb248QI1c4zoOhOMg5Od4nVeoyUf2QGfvkZ8M2y vD6v036UCjgozHFF4qPDup5YuMWLEiennSvZ2hwKHJuLqPZxRBZ1qPH3WbeagiwL6885 XYMg== X-Received: by 10.107.30.69 with SMTP id e66mr34409440ioe.76.1436566564242; Fri, 10 Jul 2015 15:16:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.68.132 with HTTP; Fri, 10 Jul 2015 15:15:24 -0700 (PDT) In-Reply-To: References: <559EEE98.8080303@starynkevitch.net> <55A00351.2050604@inria.fr> From: Gabriel Scherer Date: Sat, 11 Jul 2015 07:15:24 +0900 Message-ID: To: Raoul Duke Cc: OCaml Content-Type: multipart/alternative; boundary=001a1140f33ac20b8d051a8cb732 Subject: Re: [Caml-list] Native compiler for oCaml on System Z --001a1140f33ac20b8d051a8cb732 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There were in fact at least two serious attempts at a LLVM port: - one by Colin Benner, https://github.com/colinbenner/ocamlllvm http://oud.ocaml.org/2012/abstracts/oud2012-paper7.pdf (the paper above briefly discusses GC issues) - one by Rapha=C3=ABl Amiard, https://github.com/raph-amiard/CamllVM https://www.irill.org/blog/camllvm-a-llvm-based-runtime-for-ocaml (in the spirit of University Pierre et Marie Curie, this compiler goes from OCaml bytecode to LLVM programs, instead of being a harder-to-deploy native-code compiler backend) Both cited the GC interface and the slowness of exceptions (relative to the exceptionnally fast OCaml runtime exception handling on which many programs rely). These difficulties had been correctly foreplanned by Xavier Leroy in his 2009 caml-list message http://caml.inria.fr/pub/ml-archives/caml-list/2009/03/3a77bfcca0f90b763d12= 7d1581d6a2f1.en.html There has been recent developments on the GC support front in the LLVM community, notably the work of Philip Reames on "statepoints" as an alternative approach to GC support (that should support eg. passing roots in registers): http://www.philipreames.com/Blog/2014/10/21/statepoints-vs-gcroot-for-repre= senting-call-safepoints/ Regarding exceptions, I would guess a necessary evil would be to do more static analyses inside the OCaml backend to detect when exception usage can be refined to less generic constructs (eg. the experiments of Alain Frisch on "static raise": https://www.lexifi.com/blog/static-exceptions ). Degraded exceptions are also a source of performance issues on other backends such as js_of_ocaml. On Sat, Jul 11, 2015 at 2:47 AM, Raoul Duke wrote: > > Targeting LLVM or GCCJIT is an interesting but separate project. > > At least one attempt were made in the past to target LLVM, running into > > problems with the (exact) GC interface of OCaml. Maybe LLVM improved > > recently in this department, and maybe GCCJIT can handle it too. If > > not, I think it's a dead end. > > > For posterity, and for the sake of curiosity, might someone in the > know succinctly explain what the (exact) GC interface road blocks > were? Thank you! > > -- > 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 > --001a1140f33ac20b8d051a8cb732 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There we= re in fact at least two serious attempts at a LLVM port:
- one by = Colin Benner,
=C2=A0 https://github.com/colinbenner/ocamlllvm
=C2=A0 http://oud.ocaml.org/2012/= abstracts/oud2012-paper7.pdf
=C2=A0 (the paper above briefly d= iscusses GC issues)
- one by Rapha=C3=ABl Amiard,
=C2=A0 https://github.com/raph-amiard= /CamllVM
=C2=A0 https://www.irill.org/blog/camllvm-a-llvm-based-r= untime-for-ocaml
=C2=A0 (in the spirit of University Pierre et= Marie Curie, this compiler goes from
=C2=A0=C2=A0 OCaml bytecode = to LLVM programs, instead of being a harder-to-deploy
=C2=A0=C2=A0= native-code compiler backend)

Both cited the GC interface and= the slowness of exceptions (relative to the exceptionnally fast OCaml runt= ime exception handling on which many programs rely). These difficulties had= been correctly foreplanned by Xavier Leroy in his 2009 caml-list message=C2=A0 http://caml.inria.fr/pub/ml-archi= ves/caml-list/2009/03/3a77bfcca0f90b763d127d1581d6a2f1.en.html

<= /div>There has been recent developments on the GC support front in the LLVM= community, notably the work of Philip Reames on "statepoints" as= an alternative approach to GC support (that should support eg. passing roo= ts in registers): http://www.philiprea= mes.com/Blog/2014/10/21/statepoints-vs-gcroot-for-representing-call-safepoi= nts/

Regarding exceptions, I would guess a necessary = evil would be to do more static analyses inside the OCaml backend to detect= when exception usage can be refined to less generic constructs (eg. the ex= periments of Alain Frisch on "static raise": https://www.lexifi.com/blog/static-ex= ceptions ). Degraded exceptions are also a source of performance issues= on other backends such as js_of_ocaml.


On Sat, Jul 11, 2015 at 2:4= 7 AM, Raoul Duke <raould@gmail.com> wrote:
> Targeting LLVM or GCCJIT is an intere= sting but separate project.
> At least one attempt were made in the past to target LLVM, running int= o
> problems with the (exact) GC interface of OCaml.=C2=A0 Maybe LLVM impr= oved
> recently in this department, and maybe GCCJIT can handle it too.=C2=A0= If
> not, I think it's a dead end.


For posterity, and for the sake of curiosity, might someone in the know succinctly explain what the (exact) GC interface road blocks
were? Thank you!

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a1140f33ac20b8d051a8cb732--