From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p2PAqjkB008698 for ; Fri, 25 Mar 2011 11:52:45 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4DAHFzjE3VhjEVd2dsb2JhbAClUxQBDAoTFCWITbsxhWkEkEkG X-IronPort-AV: E=Sophos;i="4.63,242,1299452400"; d="scan'208";a="91115919" Received: from ihsmtp01cons.lis.interhost.com ([213.134.49.21]) by mail4-smtp-sop.national.inria.fr with ESMTP; 25 Mar 2011 11:51:57 +0100 Received: from [192.168.1.64] ([178.166.9.223]) by ihsmtp01cons.lis.interhost.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Mar 2011 10:51:56 +0000 Message-ID: <4D8C73C8.6020801@inescporto.pt> Date: Fri, 25 Mar 2011 10:51:52 +0000 From: Hugo Ferreira User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Fabrice Le Fessant CC: caml-list@inria.fr References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr> In-Reply-To: <4D8BD02D.1010505@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2011 10:51:56.0366 (UTC) FILETIME=[A8A9C6E0:01CBEADA] Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? Hello, First and foremost just let me say that I am not an expert on this issue but I have a vested interest in Ocaml's support for parallel execution, hence my comment. On 03/24/2011 11:13 PM, Fabrice Le Fessant wrote: > Hi, > > Actually, I had a discussion two weeks ago with Xavier and Damien > about this issue. There is some kind of agreement that the ocaml way of > supporting multicore would be to have several runtimes running in the > same process, in different threads. That way, the GC would still be > mono-threaded, so almost no speed loss for mono-threaded programs (i.e. > currently all OCaml programs ;-) ). There would be some kind of "fork" > function, that would create a new thread running a function in a new > heap, probably generated by a copy-on-need algorithm. The different > threads would not share heap memory, but would be allowed to share > structures outside of their heaps, probably for simple types like > strings and int/float arrays (or using the Ancient library). > I see the restriction that shared data be simple data types as a significant disadvantage. In my experience being able to access complex data structure is crucial. Whenever I see this constraint I keep asking: why not bite the bullet? Why not take the bull by the horns and do it as well as possible? If not, I believe its a waste of precious time. That being said, I have a question: why will the proposal below not work? Assuming all shared data structures are immutable is it possible to: 1) Use a GC that is thread aware. 2) Let each thread have its own thread-aware GC. 4) Mark the shared data by tagging it with the owner of the data and counting the number of threads using this data. 5) Each thread has it own local GC. This GC only manages the thread's local data that is not shared with any other. 6) If data is shared, the thread that shares immediately marks it as shared. 7) If a thread terminates before the shared data can be collected (that is when the shared counter is not 0), the ownership is reverted to any one of the sharing threads. 8) The last thread to hold a shared data structure is responsible for GC. Am I totally off the mark here? Regards, Hugo F. P.S: Note that the above can be "enhanced" by for example identifying read-only data in order to facilitate GC. > Now, there are still two problems: > (1) We don't know yet how to implement that in a portable way. TLS > (Thread-local storage) is only available on a few architectures. And not > using TLS implies non-backward compatible changes to the FFI > (Foreign-Functions Interface), i.e. all stub libraries would have to be > rewritten. > (2) As Gerd pointed it, there are not so many programs that would > benefit from that. So it is not currently on the top of our priority > list, although I am planning to give it a try in the next months, at > least for the TLS version. > > Cheers,