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 A7E317EE99 for ; Wed, 8 Jan 2014 14:38:25 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.186 as permitted sender) identity=helo; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoICAHNUzVLU4366lWdsb2JhbABZg0ODVLZxgRMWDgEBAQEHDQkJEiqCJQEBAQMBI1YFCwsOCioCAlcGEwkSh2EMCaocmlUXiTqEegEBKSYHgi9AgUgEjwaHKIMZhRAFjn6BcA X-IPAS-Result: AoICAHNUzVLU4366lWdsb2JhbABZg0ODVLZxgRMWDgEBAQEHDQkJEiqCJQEBAQMBI1YFCwsOCioCAlcGEwkSh2EMCaocmlUXiTqEegEBKSYHgi9AgUgEjwaHKIMZhRAFjn6BcA X-IronPort-AV: E=Sophos;i="4.95,624,1384297200"; d="asc'?scan'208";a="52264135" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Jan 2014 14:38:25 +0100 Received: from office1.lan.sumadev.de (dslb-088-069-138-108.pools.arcor-ip.net [88.69.138.108]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MbLNo-1Vi7Sm3b7M-00JbGM; Wed, 08 Jan 2014 14:38:09 +0100 Received: from [192.168.5.106] (dslb-088-069-138-108.pools.arcor-ip.net [88.69.138.108]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 76CA8C00D3; Wed, 8 Jan 2014 14:38:08 +0100 (CET) Message-ID: <1389188287.3822.10.camel@thinkpad> From: Gerd Stolpmann To: Mark Shinwell Cc: Yotam Barnoy , Ocaml Mailing List Date: Wed, 08 Jan 2014 14:38:07 +0100 In-Reply-To: References: <1389126940.2692.4.camel@zotac> <1389181001.2999.46.camel@e130> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-6AcmWxbJBlnZZUHRBrmF" X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-Provags-ID: V02:K0:nxNQixgslmFN2pKoDt2L7qtrNIt/JseIIWM8vJxXSFN XAjecb05jReogLOpBwc+CZjWeVxDfnI0E1sD3f1kByYp+BODiu TEeXEGBrhwRC2Ijwifdpla++UnXY2TQZiT9vX4bWPdVhA76iZN toYd9wFNAvk+Dvc3LOO4u9UHtPQtxsrslHZl313Vgn5+gONemj 5UTMnRK5yZLk51nUdEAUsRb1zkFNyxcDzDFWn1TXm0TL0P6Q3n WLw/TfwKzXQ5oNIOSyCD5irB2I+IEke12G52UpBObVMpOSStGk XvpsvxuMXLn4PNwqL6Ps9279SmXnp8OBg7/Ks2Tl32T0q7m/Ty 53btLI1HpJMsirb8CV81UlS8sfFTrwxW46DfgW716 Subject: Re: [Caml-list] Concurrent/parallel programming --=-6AcmWxbJBlnZZUHRBrmF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch, den 08.01.2014, 11:55 +0000 schrieb Mark Shinwell: > On 8 January 2014 11:36, Gerd Stolpmann wrote: > > There is a workaround in place - so far the OS supports it: thanks to > > Xavier the symbols caml_modify and caml_initialize are declared as weak > > in 4.01, allowing them to be redefined in executables. Netmulticore > > redefines these symbols with their pre-4.01 functions. > > > > This isn't optimal yet, because the old write barriers are a bit slower, > > and because this introduces a very low-level dependency on the current > > version of Ocaml. Nevertheless, it works for now. (Ideas for a better > > solution are highly welcome.) >=20 > Jeremie Dimino and myself have a somewhat embryonic proposal > that should permit most of the write barrier to be > circumvented for out-of-heap access, and also avoid the page > table test. We'll send mail to the list in due course once > we've had time to think about this further. I'm very curious to hear about that. So far I have only the idea to override the :=3D operator selectively in all modules that want to modify out-of-heap values: let ( :=3D ) =3D Netmcore_heap.assign h where Netmcore_heap.assign is a C function that tests whether the destination address is in the out-of-heap address space of h. If so, the assignment can be done directly. If not, it just falls back to a normal caml_modify. This solution isn't nice, though, because it can be very problematic to have the extra indirection of ref. So, what I'm searching for is a way to turn any record mutation into an external C function call (or at least to parametrize the write barrier somehow). Gerd > Mark >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-6AcmWxbJBlnZZUHRBrmF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAABAgAGBQJSzVTAAAoJEAaM4b9ZLB5TiWgH/2G1anPuM2AJRkFEkCaU+vOh TEIPhSRvyoMwxhgcwPbHLqAHu2yJk/+YKjEu+fjGG698AD62aJkcjLhJOPOvvuqL SQxWt4nUFyt6dBu1tdxAxhN4PeXnmRTTzD0A/NwKhHLjeVcU00RidLe6h2jt1MnU AMyLOpj1DNIWkWEqj4h9XeMBlamTMiWh6oVuic7lhW8BO/++FqKi973p5Gxk+tov wvBKg8L1gc2GlxkJXFK5F43n9NCzeCYLcyLCRjbFNBE7DSIgZFoFomZRChmvGWk+ Zi9hd2kgqll0EW1nyuIX0/gLVS99VRog6beOisTomAWf1epnzJxauN13AWhk2bQ= =w32b -----END PGP SIGNATURE----- --=-6AcmWxbJBlnZZUHRBrmF--