220 33609 <57b118c3-5335-492e-a121-a6f149559cc4@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Phil Bouchard Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Deterministic C++ memory manager Date: Sat, 5 Aug 2017 18:32:27 -0700 (PDT) Lines: 226 Approved: news@gmane.org Message-ID: <57b118c3-5335-492e-a121-a6f149559cc4@isocpp.org> References: <68af3311-d2d7-42ff-8cfd-f8bcdc20bf0c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2099_2019411126.1501983147437" X-Trace: blaine.gmane.org 1501983152 3970 195.159.176.226 (6 Aug 2017 01:32:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 6 Aug 2017 01:32:32 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCAYTFXFZMBBBLHDTHGAKGQEYCX5MFI@isocpp.org Sun Aug 06 03:32:27 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deAQZ-0000Vk-NZ for gclcip-std-proposals@m.gmane.org; Sun, 06 Aug 2017 03:32:24 +0200 Original-Received: by mail-ua0-f198.google.com with SMTP id 110sf21095005uac.3 for ; Sat, 05 Aug 2017 18:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=FtNc5PqdyQEmrXNGvv52c13DU7MHkWEVLwmUN8ylsS0=; b=HM0r2bU2KVEKLsu65Jf7n5DpW70GQbPDEfTfBV5VsWbgljldy7TPLxoh2ohFdiVFeC DlMZ9sjgn0AWeXUdWx04koau/22p8xof/NlZnEw6OYdZI7SJKR1Euu5Ld3ItCeEFhQZp d7jsGqv3+FnMGqOxlwKvHLPnBmo+jWVskPTq95jJwsHjwt8GL6zt3Ipny/CuacgFq2IA TALKgCOpiSdEVW3Uq6gQ9XXniY7ak+UPXwT6jJ44XoLttjaAHzJuEdidOYqiCvqbVMkX Si6z4XTCctHjSJc91/gcnQnqiGs8rg7K1i8ir5jSYg/QUoER6Wr3IhE1UVr/hWdPZR05 9zZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=FtNc5PqdyQEmrXNGvv52c13DU7MHkWEVLwmUN8ylsS0=; b=EjkPmJvR6Iih4op63y0fGvuyLdTqWr/l7Wq5W6quAo6QcSmQks8ZgvouFNIuYBMy/A BXD9faef8VyXxmHmGPGPw7LsbeSEXm35jIyxndYZ32lCRcuiYsuytTJk4spiev4E+CEC zs8MDjLYrxnVSmt16xNYu4gUicoC+enUq+XTEvJOPbZ2OgKJqzzAnmTRunqEwGAfsKM1 yPcorsEWykNe5wyVJRnF8z00wO+njKeNSt23+l1JNy42ey4RECbnX0qAwDj1JhoDGk1n /Nx9cM/RnQZn3pMdagnpFjnlHJLIVLEufDAIWbr4L8U6GHfWdOjcI3U5apfwEnbnJfMD jF1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=FtNc5PqdyQEmrXNGvv52c13DU7MHkWEVLwmUN8ylsS0=; b=nMA09y64XgzW+LHS+AkU31cLVVkd+HDYwr8q3P2WHID6FKi8rUXxfCERfoWU9sZspS NH92qPsHubWt2zhITlwY7BwXhqn7aOh3GLaaymyD8c9ZKuUKl5YGPx4oNeHYtnflPqV/ cY3K38Ki+5L1akVYdDMkvzXFAL9QKondeMqZfsd2wPiXE+bbXZegTayklzJ4stO/zMaD h0/z9B6r5a/xfnO08Zta67o9I4Cj1LQ9++QxEdunvac7EeFCcyvGZQeD83g6O5Hn7S0E XYaH2t0OOLMCIorP7ShV/MyOFow7wnbY+2far18uAGjRUqorO65gGLywaBY01A+m5rrC cnrQ== X-Gm-Message-State: AIVw111TmXWBPnQpYpuv7G2xuR5C2Zf9DGcJm2SmCeYFrTZ82Rs8mFpu 4dN4ZB2fAX/shThl X-Received: by 10.159.49.72 with SMTP id n8mr4993821uab.20.1501983149292; Sat, 05 Aug 2017 18:32:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.33.85 with SMTP id h82ls5640362ioh.45.gmail; Sat, 05 Aug 2017 18:32:28 -0700 (PDT) X-Received: by 10.31.157.209 with SMTP id g200mr36669vke.9.1501983147965; Sat, 05 Aug 2017 18:32:27 -0700 (PDT) In-Reply-To: X-Original-Sender: philippeb8@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:33609 Archived-At: ------=_Part_2099_2019411126.1501983147437 Content-Type: multipart/alternative; boundary="----=_Part_2100_2040077340.1501983147437" ------=_Part_2100_2040077340.1501983147437 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, August 4, 2017 at 6:40:45 PM UTC-4, Arthur O'Dwyer wrote: > > On Friday, August 4, 2017 at 1:07:31 PM UTC-7, Phil Bouchard wrote: >> >> Hi ISO C++,=20 >> >> I have developed a deterministic memory manager in C++ and I was=20 >> wondering if ISO C++ would be interested to hear more about it. >> >> For the moment I have included my solution in a brand new language I cal= l=20 >> "BB++" because I need to add functionality that C++ doesn't yet have suc= h=20 >> as: >> - to add instances of an object implicitly as each scope; >> - to add implicit references to these objects in top-level classes >> - to overload 'operator .' >> - to use 'auto' for member variables instead of 'decltype' >> - to add metadata of the classes in order to propagate the proxy=20 >> associated to the pointers within those classes >> >> The homepage of my project is: >> https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp >> >> And I have a 17 minutes presentation available here: >> https://youtu.be/GrNDYWyasxg >> >> Please let me know if this is the type of research you are interested in= ..=20 >> The work is a step away from being production ready. It has to be noted= =20 >> that Root.Ptr is already faster than Shared.Ptr in multithreaded mode. >> > > It would help if you could edit down that YouTube video to cut all the=20 > dead air; it's 17 minutes of which the relevant 5 minutes is scattered=20 > around separated by painful silent sections. Even at 200% playback speed,= =20 > it's a slog. > Certainly for your present purposes, *nothing* prior to 6m22s is=20 > relevant. (Anyone who cares already knows how mark-and-sweep and=20 > refcounting work, and doesn't need a tutorial on the subject.) > > You never show code or diagrams for root_ptr in the video, but from the= =20 > usage example and caveats, I infer that it is (almost?) exactly what Herb= =20 > Sutter called a "deferred_heap" at CppCon 2016. > > https://internals.rust-lang.org/t/herb-sutter-deferred-heaps-and-pointers= /4183 > Of course everyone has their own implementation of this idea; and there= =20 > are plenty of hybrids, such as "local arena allocators", or mixing in a b= it=20 > of refcounting to get Objective-C's "autorelease pools", or mixing in a b= it=20 > of RCU to get "RCU domains", or whatever. > > Starting around 12m45s, the examples seem to be concerned entirely with= =20 > showing examples of successful escape analysis =E2=80=94 that is, you cre= ate a=20 > "node_proxy" (a.k.a. deferred_heap) and allocate some objects in that hea= p,=20 > and then you return a pointer to one of those objects from the current=20 > function. Normally this would cause dangling-pointer/use-after-free error= s,=20 > but in this case your BB++ language is doing some sort of "escape analysi= s"=20 > to promote the returned object into the surrounding scope. Some explanati= on=20 > of this promotion mechanism would be useful, since it's the one thing=20 > that's not obvious how to do in today's C++. > In the following video, I am explaining how objects of a lower scope are=20 being promoted to a higher scope (please fast forward to 10:15): https://youtu.be/OBnpFUVEVe4 I added 5 slides explaining how objects are being promoted and I've=20 renarrated everything after 6:21. I'm keeping the beginning because I am=20 targeting newbies on the subject as well. I hope that's a good explanation because sharing this information publicly= =20 is a point of no return for me. Sincerely, -Phil --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/57b118c3-5335-492e-a121-a6f149559cc4%40isocpp.or= g. ------=_Part_2100_2040077340.1501983147437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, August 4, 2017 at 6:40:45 PM UTC-4, Art= hur O'Dwyer wrote:
On Friday, August 4, 2017 at 1:07:31 PM UTC-7, Phil Bouchard wrote= :
Hi ISO C++,

I have developed a deterministic memory manager in C++ and I was=20 wondering if ISO C++ would be interested to hear more about it.

For the moment I have included my solution in a brand new language I call=20 "BB++" because I need to add functionality that C++ doesn't y= et have=20 such as:
- to add instances of an object implicitly as each scope;
- = to add implicit references to these objects in top-level classes
- to ov= erload 'operator .'
- to use 'auto' for member variables= instead of 'decltype'
- to add metadata of the classes in order= to propagate the proxy associated to the pointers within those classes

=

The homepage of = my project is:
https://github.com/= philippeb8/root_ptr/tree/bb++/bbpp2cpp

And I have a 17 minutes presentation ava= ilable here:
https://youtu.be/GrNDYWyasxg

Please let me know if this is the type of research you are interested in. The work is a step away from being production ready. It has to be noted th= at Root.Ptr is already faster than Shared.Ptr in multithreaded mode.


It would help if you could edit down th= at YouTube video to cut all the dead air; it's 17 minutes of which the = relevant 5 minutes is scattered around separated by painful silent sections= .. Even at 200% playback speed, it's a slog.
Certainly for you= r present purposes, nothing prior to 6m22s is relevant. (Anyone who = cares already knows how mark-and-sweep and refcounting work, and doesn'= t need a tutorial on the subject.)

You never show = code or diagrams for root_ptr in the video, but from the usage example and = caveats, I infer that it is (almost?) exactly what Herb Sutter called a &qu= ot;deferred_heap" at CppCon 2016.
Of course everyone has their own implementation of this idea;= and there are plenty of hybrids, such as "local arena allocators"= ;, or mixing in a bit of refcounting to get Objective-C's "autorel= ease pools", or mixing in a bit of RCU to get "RCU domains",= or whatever.

Starting around 12m45s, the examples= seem to be concerned entirely with showing examples of successful escape a= nalysis =E2=80=94 that is, you create a "node_proxy" (a.k.a. defe= rred_heap) and allocate some objects in that heap, and then you return a po= inter to one of those objects from the current function. Normally this woul= d cause dangling-pointer/use-after-free errors, but in this case your = BB++ language is doing some sort of "escape analysis" to promote = the returned object into the surrounding scope. Some explanation of this pr= omotion mechanism would be useful, since it's the one thing that's = not obvious how to do in today's C++.

=
In the following video, I am explaining how objects of a lower s= cope are being promoted to a higher scope (please fast forward to 10:15):https://youtu.be/OBnpFUVEVe4

I added 5 slides ex= plaining how objects are being promoted and I've renarrated everything = after 6:21. I'm keeping the beginning because I am targeting newbies on= the subject as well.

I hope that's a good exp= lanation because sharing this information publicly is a point of no return = for me.


Sincerely,
-Phil<= /div>

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/57b118c3-5335-492e-a121-a6f149559cc4= %40isocpp.org.
------=_Part_2100_2040077340.1501983147437-- ------=_Part_2099_2019411126.1501983147437-- .